次のような構造の既存のデータベースがあります。
user
user_profile
user_permissions
user_statistics
各テーブルには、次のように、各テーブルを結合するために使用される一意の列があります。
SELECT *
FROM user
INNER JOIN user_profile ON user.user_id = user_profile.user_profile_id
INNER JOIN user_permissions ON user.user_id = user_permissions.user_permissions_id
INNER JOIN user_statistics ON user.user_id = user_statistics.user_statistics_id
WHERE user_id = 1
このようにすることに何か問題がありますか?それとも、結合が不要になるように、多数の列を持つ 1 つのテーブルを作成する方がよい方法ですか?
これは古典的なデータベース設計です。これは「正規化」と呼ばれ、一般的にベストプラクティスと見なされています。
データベースを非正規化する理由があります-パフォーマンスは古典的です。ただし、これには通常、保守性と一貫性が犠牲になります。通常、これは非常に極端なデータサイズでのみ意味があります。説明するスキーマは、結合が問題になることなく、膨大な数のレコードに拡張できる必要があります。
また、「user」にリンクされているテーブルのいくつかには、特定のユーザーの複数のレコードがあると推測しています。「statistics」には通常、特定のユーザーの行がたくさんあります。権限には、ユーザーの権限ごとに1つの行が含まれる場合もあります。1つの大きなテーブルでそれをモデル化するのは恐ろしいことです。
一部の設計者は、論理的に分離されたデータ用に別個のテーブルを作成することを好みます。したがって、設計者はこれが「ユーザー」から論理的に分離されたデータであると感じたため、ユーザーごとに1行の「user_profile」テーブルをデザインに含めることができます。たとえば、さまざまなビジネス環境で変化します。私の見解では、これは主にスタイルの問題です。
この場合、結合によってデータベースの速度が低下することはありません。リレーショナルデータベースの要点は、この種のシナリオの管理を非常に効率的に行うことです（「リレーショナル」とは、データを関連付けることができるという事実を指します）。
データベースをそのままリレーショナルにする方が良いです。この構造により、データの異常のリスクが排除され、規模とドメインの詳細を変更する準備が整います（つまり、新しい種類のアクセス許可を追加するとどうなりますか？）
JOINはデータベースの機能の自然な部分であり、非常に効率的です。
これが優れた方法である理由の詳細は、データベースの正規化と呼ばれるものにまとめられています。