ツイート3「users」テーブルの「id」「posts」テーブルの「user_id」と対応するこれにより、特定のユーザーが投稿したすべてのポストを効率的に取得することが可能になります例えば、ユーザーA(id=1)が投稿したポストを取得するには、「posts」テーブルで「user_id」が1の行を全て抽出することで取得できるようになりますこの場合、「posts」テーブルにはユーザーの詳細を直接保存する代わりに、「users」テーブルへのリンク(つまり、ユーザーID)を保存します。これにより、ユーザーの詳細は「users」テーブルで管理され、情報が変更された場合もその箇所を更新すれば良いことになります例えば、ユーザーAがメールアドレスを変更した場合、ユーザーAが投稿した全てのツイートでメールアドレスを更新する必要はなく、「users」テーブルの該当行だけを更新すれば良いです。これはエンジニアのスキルに依存します利用企業が多い:多くの企業がリレーショナルデータベースを使用しているため、その使用が当然と思われてしまいます設計に依存してしまう:テーブル構造が不適切だと全体のアプリケーションのパフォーマンスに影響を与える可能性がありますリレーショナルデータベースの種類MariaDB:MySQLの上位互換であるMariaDBは、MySQLの機能に加えて新たな機能が搭載されています。大規模な設計が可能で、ビッグデータなどに対応し、マルチサーバーによりスケーリングが可能で本番環境に強いです。LinuxOSではデフォルトで使用されるデータベースですPostgreSQL:ビジネス向けのリレーショナルデータベースです。超大規模な設計に対応し、拡張性が高く、将来的に必要とされる機能を追加することが可能です。NoSQLをサポートしているため、key-valueストア形式も使用できますOracleDB:伝統的な商用データベースであり、最低42,000円で使用が可能です。大規模な設計に対応し、サポートが充実しています。Aurora:クラウド時代のリレーショナルデータベースで、MySQLの5倍、PostgreSQLの3倍の速度を持ちます。MySQL、MariaDB、PostgreSQLとの互換性が高く、開発やステージング環境にこれらを使用し、本番環境にはAuroraを使用することができます。AWSの安心感があり、バックアップや復帰などのトラブルを自動で解決しますSQLにおける3つのJOINSQLにおけるJOINは、異なるテーブル間で関連性を持つデータを取得するための重要な操作です。1対1、1対多、多対多のリレーションは、以下のように理解できます。このタイプのリレーションは最もシンプルな形で、一つのレコードが他のテーブルの一つのレコードに直接対応しています。このタイプは一つのレコードが他のテーブルの複数のレコードに対応しています。「いいね」機能では、一つのツイートに対して、複数のユーザーが「いいね」を押すことができます。このタイプは複数のレコードが他のテーブルの複数のレコードに対応しています。これは一般的に中間テーブルを用いて実現されます。外部キー:tags.id以上でシンプルメモアプリのデータベース設計を完了とします最後に本記事は基礎的な部分ですが、改めてデータベースの設計部分を学んで業務でなんとなく使っていたテーブルとリレーションの意味を把握しやすくなった気がしましたまた、リレーションに関しては余計なリレーションを外すだけで爆発的に軽くなったこともあるので今一度、テーブルのリレーション周りをなんとなく見直してみるのも良いかもですねt1k2aうつ病を乗り越えたへっぽこエンジニアバッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。