17

私は Ruby on Rails を扱っていますが、この質問はそれよりも広く、データベース設計全般に当てはまると思います。

1 つのモデルを複数のテーブルに分割するのは、どのような場合に適していますか? たとえば、User モデルがあり、モデル内のフィールドの数が実際に増え始めているとします。たとえば、ユーザーは自分のウェブサイト、誕生日、タイムゾーンなどを入力できます。

モデルを分割することの利点または欠点はありますか。たとえば、User テーブルにはログインや電子メールなどの基本情報しかなく、すべての User には UserInfo のような別のテーブルがあり、別のテーブルは UserPermissions です。 UserPrivacySettings などの別のものはありますか?

編集：これにさらに光沢を加えるために、それらに固有のページを除いて、ほとんどのフィールドはめったにアクセスされません。たとえば、誕生日などは、誰かがユーザーのプロフィールをクリックした場合にのみアクセスされます。さらに、一部のフィールド (めったにアクセスされない) は、非常に大きくなる可能性があります。ほとんどのフィールドは、空白または nil に設定される可能性があります。

4

3 に答える 3

9

一般に、1 対 1 の関係にあるものを同じテーブルに入れることをお勧めします。ユーザーベースに女王またはパディントン ベアが含まれていない限り、ユーザーの誕生日は 1 つしかないため、それを USERS テーブルの属性にする必要があります。一対多の関係を持つものは、別のテーブルにある必要があります。そのため、ユーザーが複数のプライバシー設定を持つことができる場合は、必ずそれらを分割してください。

一度にすべてのユーザー情報を取得したい場合、1 つのテーブルを複数のテーブルに分割すると、クエリがより複雑になったり遅くなったりする可能性があります。一方、個別の方法でのみクエリまたは更新される一連の属性がある場合、そのデータを保持する別のテーブルを持つことは適切な考えです。

于 2010-02-16T07:32:55.620 に答える
3

これは、分析の対象となる状況です。

このようなテーブル内の多くのフィールドが NULL であり、グループ化できることがわかった場合(例: UserContactInfo)、独自のテーブルに情報を抽出することを検討します。

まばらに入力されたデータのみを含む数十または数百のフィールドを含むテーブルを作成することは避けたいと考えています。

むしろ、データを論理的にグループ化して、ほとんどすべてが入力されているフィールドを含むメイン テーブルを作成します。次に、データのサブセット (連絡先情報、個人的な興味、仕事関連の情報など) を UI で表すのとほぼ同じように、個別のテーブルに作成できます。

于 2010-02-16T07:30:24.533 に答える
3

行に多くの列がある場合、特に通常は一部のフィールドのみが必要な場合、行の取得はよりコストがかかります。また、アドレスのコンポーネントなどを別のクラスにホスティングすることも DRY のケースです。一方、オブジェクトのすべてのフィールドが必要な場合は、複合クエリの実行に時間がかかります。

私は通常、コードを読みやすくするためだけに (つまり、アドレスのような実際に再利用可能な部分を除いて)、複数のテーブルにクラスを分散することはしません。

于 2010-02-16T07:31:58.873 に答える