私はすべてのアドレス情報関連のカラムを持つ会社、顧客、サプライヤなどのテーブルを持っています。カラムを新しいテーブルに分割する場合
私は新しいテーブル 'アドレス'を作成し、それにすべてのアドレス列を分けるべきかどうかを判断しようとしています。
すべてのテーブルにアドレス欄を使用するのは使いやすく、クエリが簡単ですが、良いデザインの観点からするのが正しいかどうかは分かりません。
住所の内容は私にとって重要ではありません。これらの住所を意思決定プロセスで確認したり使用したりすることはありません。現在、私はアドレス情報を持っている5つのテーブルを見ています
これは、次のとおりです。
したがって、基本的に、住所の場合は、顧客ごとに1つ以上の住所があるかどうかによって異なります。 2つ以上ある場合は、新しいAddressesテーブルに置き、各アドレスにCustomerIDを付けます。一般的なAddressテーブルを作成し、それをcompany/customer/supplierテーブルにマップするのは、過度の作業です（ほとんどの場合、それに依存します）。
オブジェクト間の多対多の関係でアドレスをマップすることは、しばしば過度の（そして危険な）ことです（これを行うと、アドレスが魔法のように変わるように見えることがあります）。
1つの大きなルールは次のとおりです。
これらのアドレスを自分のテーブルの範囲内でのみ使用している場合、それらを自分のテーブルに移動することは実際のメリットではありません。
基本的には、それは努力する価値があるようには聞こえません。
投票の理由がわかります。 thx –
それらを独自のテーブルに移動することの本当の利点は、いくつかの場所でそれを維持するのではなく、単一のコヒーレントなアドレススキーマを単一の場所に維持するという価値を無視します。（私は、企業がアドレスフィールドの長さが会社と顧客のために異なってしまったときに、これに関連するバグよりも狂っているのを見た。）また、二重否定は混乱している。 –
@McWaffle：しかし、これは "それが頼りになる"ものです。アドレスを持つエンティティが2つまたは3つしかない場合は、システムにとって脅威ではありません。アドレスを使用するエンティティが10個あり、ファーストクラスのオブジェクトとしてアドレス自体を処理する一般的な方法が必要な場合は、私はあなたに同意する傾向があります。 –
はい、独自のテーブルにアドレスを区切る必要があります。聞くことを知ることは賢明です。ここで重要な点は、アドレスの一般的な形式は誰であるかにかかわらず同じであることです。顧客、会社、サプライヤ...これらはすべて住所用のフィールドが同じです。
これは価値があるのは、アドレスを原子要素として扱うことができることです。つまり、アドレスに関連するすべての機能を一般化して、複数のテーブルを扱うことを心配するのではなく、関連するスキーマのドリフトを発生させるのではなく、1つのテーブルだけを扱うことができます。
これは必ずしも必要ではありません。通常、住所を含む多くのスキーマドリフトはありません。 –
私は同意しません。それ自身のための正規化は、必ずしも正しい方法ではありません。これは、データの目的と実際の反復データの割合に依存します。データが繰り返される可能性がない場合は、スキーマを正規化することは目的ではないと言えます。 – BenAlabaster
これは正しいです。通常、スキーマのドリフトはあまりありませんが、顧客とサプライヤ間のアドレスフィールドの長さ（varchar（80）varchar（120） ）。 IMOでは、正規化に関わる作業が比較的少ないため、後でリスクが高い可能性があります。 –
テーブルが重複している場合（つまり、同じ組織が会社テーブルとサプライヤテーブルの両方に入力されている場合）、アドレスは常に両方のテーブルで同じである必要があります。他の3つのテーブルから外部キーを持っています。そうすれば、変更があったときに1つの場所で更新するだけで済みます。
3つのテーブルが完全に独立している場合は、データを別のテーブルに移動してもあまり効果がありません。
これはDatabase Normalizationと呼ばれます。そして、はい、あなたはそれらを分割したいと思っています。それ以外の理由がなければ、将来的に必要な場合は、コードとクエリを適切に配置することがより困難になるからです。
基本的には、データベースを3次標準フォームで設計する必要があります（単純なアプリケーションの場合でも）。パフォーマンスやロジスティック上の理由ではないケースがいくつかありますが、それを第3の正規形とし、正しい方法を知った後で不正行為を学ぶ）。
EDIT：これを拡張し、私が他の投稿に行ったコメントを追加するには、単純なデザインから始めて、コードとリファクタリングを開始することに大きな信念を感じますより複雑でオブジェクト指向のより多くの原則が適切であろう。しかし、実稼働中のデータベースのリファクタリングはあまり簡単ではありません。それはすべてROIに関するものです。正規化されたデータベースを最初から設計するのは簡単ではありません。あまり設計されていないデータベースの結果は致命的なものになる可能性があります。
私はそれが完全にデータベースの目的によって異なると思います。確かにすべてのアドレス情報は構造的に同じであり、理論的な観点からは、すべてが親テーブルからキーでリンクされた単一のテーブルにあるべきです。
しかし、パフォーマンスとクエリの観点から見ると、それぞれのテーブルにそれらを保持することは、レポートの観点から物事を単純化します。彼らは関係なく、などピックアップ場所、配信場所、顧客
にいるかどうかのすべての場所だ -
私は私の現在の会社の状況アドレスが実際に論理的に同じです[物流]を持っています私の場合、私は彼らが最も確かにすべてが一つのテーブルにあるべきだと言いたい。しかし、それがサプライヤー、顧客、連絡先情報の視点から見ると、私は理論的には1つのテーブルにアドレスを持たせるのはいいのですが、実際にはデータはほとんどないと思うので繰り返される。
私はDaveに同意しません。多対多のアプローチ（アドレス< - > User）は安全で、非常に有利です。
顧客が移動すると、アドレステーブルのアドレスは変更されません。代わりに、新しいアドレスがAddressテーブルにあり、顧客などがそのレコードにリンクされています。新しい住所がまだ表にない場合は、住所が追加されます。
アドレスレコード自体が変わるのですか？はい、このような場合には：
を変更する1テーブル内のすべてのアドレスを入れてどここれらは非常事態です繰り返しなしで報われる。任意の他の配置は、煩わしい、繰り返しのデータ入力を必要とする。
もちろん、データベースが悪用されている場合は、多対多の関係を避ける方が安全です。しかし、そのトークンによって、データベースが悪い場合は、すべてを印刷し、ファイルキャビネットに保管し、紙のコピーとのすべてのトランザクションを検証する方がよいでしょう。私の意見では、「誤用からの保護」は良い設計原則ではありません。
あなたは多対多の関係でアドレスをどのように使用するかの例を挙げることができます – kaivalya
「正規化ルールは盲目的に続かなければなりません」と思う人には神様に感謝します – BenAlabaster
@korki：確か。顧客とサプライヤを同じ場所に配置することができ、複数の住所（請求先住所、受信アドレス）を持つ可能性があります。顧客/サプライヤーレコードをアドレスにマップするためのテーブルを作成します。これは一般にあなたが望むよりも複雑で、アドレスの1つを更新すると意図しない結果が生じる可能性があるため、恐ろしいことです。 –