最近、他の開発者と、テーブルの列が多すぎる、またはモデルの属性が多すぎるとコードの臭いについて話し合った。属性が多すぎるモデルは、実行していることが多すぎるため、分割する必要があると主張する人もいます。しかし、モデルが実際にこれらの属性を必要とする場合はどうなるでしょうか。
usersテーブルの例を見てみましょう。
ユーザーは、、、、、、、
などをfirst_name持つlast_nameことができます。引数によると、私はを仮定し、別のテーブルに移動する必要があります。関連するデータがこのようにグループ化されることに同意しますが、アプリケーションがユーザーのアドレスも照会している場合、それらは2つのテーブルにあるため、よりコストのかかる操作になるのではないでしょうか。street_namecitystateagestreet_namecitystate
では、多くの属性を持つテーブルをモデル化する正しい方法は何ですか？（これらのケースも考慮する必要があります：1。行数が少なくなる2.行数が膨大になる場合）
「1つのテーブルの属性が多すぎる」という問題ではありません。これは、「間違った属性を1つのテーブルにまとめる」という問題です。テーブルのキーは、主題のエンティティまたは関係に関連している必要があります。非キー属性は、キー、キー全体、およびキー以外の何物にも依存しない（決定される）必要があります。
これは、「データの正規化」と呼ばれるものの過度に単純化されたビューです。データの正規化は、データベース内の複数の場所に同じファクトを保存する必要性を防ぐのに役立ちます。この有害な冗長性は無駄であるだけでなく、データベース自体と矛盾する可能性もあります。これは本当に苦痛です。
正規化されていないデザインを正規化されたデザインに変換するには、多くの場合、テーブルを分割する必要があります。ただし、テーブルをランダムに分割するだけではいけません。正規化ルールを学びます。それらを無視する時期を知るのに十分な専門家になるまで、それらに従ってください。
これはかなり学術的な問題です。データベースモデルを設計するとき、多くの場合、念頭に置いているのはパフォーマンスだけです。見栄えが良いという理由だけでテーブルを分割することはありません。あなたは例えばそれをします
すべてのデータベースではない場合でも、ほとんどの場合、レコードのサイズに制限があります。したがって、テーブルを分割して、データベースに効率的に格納できるようにすることができます。
クラスを設計するときはまったく異なります。クラスを分割しても、パフォーマンスには大きな影響はありませんが、メンテナンスには大きな影響があります。保守性が主な関心事であるはずです。
特にシナリオを使用するaddressと、デザインがユーザーごとに複数のアドレスに対応する場合、または同じアドレスを使用して複数の登録を追跡/トラップする場合に非常に役立ちます。
descriptionまたは、一般的なフィールドと、行を特定のタイプの住所（たとえば、、、など）としてtypeタグ付けする列がある、より一般的な住所テーブルの実装を検討することもできます。emailhouseofficespouse
物語の教訓は、この物語の教訓は、それが複数ある可能性がある場合は、別のテーブルを用意することです。過剰な正規化は、次のような情報のために余分なテーブルを1つか2つジャンプすることに利点がない場合にのみ設定されます。