私は配信システムを構築しています。今のところ、私のデザインは次のようになります。
問題は、非常に頻繁に、次のような (非常に階層的な) 構造 (配列、json、オブジェクトなど) が必要になることです。
これに関する問題は、StreetAddress、DeliveryPoint、および Customer の多くの繰り返しが作成されることです。これは、各 Itinerary が多数のそれらを作成し、旅程が他のものと非常によく似ているためです。良い点は、ほんの数回の結合ですべてがきれいになることです。
最初のスキーマでは、2 番目の構造を作成するのは非常に奇妙ですが、可能です。
繰り返しを制御し、上記の構造に対して簡単にクエリを実行できるスキーマを取得する方法についてのアイデアはありますか?
私は使用しています：
[スキーマをどのように描いたのか知りたい人のために: www.griffy.com]
繰り返しと正規化は、必ずしも相反する問題ではありません。
基本的な問題は次のとおりです。
正規化は繰り返し自体を気にするのではなく、機能依存性を気にします
繰り返しは間違った質問です。機能依存性は正しい質問です。場合によっては、アドレスの機能依存関係を判断するのが非常に困難な場合があります。これは、非常に多くの規則が存在するためであり、たとえそうしたとしても、フォーマットの問題が発生する可能性があります。
この問題の根底にたどり着く簡単な方法は、特定のデータが変更される理由を尋ねることです。優れた正規化された設計は、特定のデータを変更する必要がある理由を制限します。さて、それを念頭に置いて、顧客のために過去の場所を保存する必要があるように見えますが、少し違うことをしたいと思うかもしれません.
それ以外の：
Delivery -> customer -> street address -> itinerary
私には、次のほうが理にかなっているように見えます。
Customer -> street address
と
delivery -> itinerary -> street address
このモデルでは、情報が重複している可能性があり、有効な日付と有効期限を示す日付を住所に含める必要がある場合がありますが、特にアドレスが既に提起している正規化の問題を考えると、正規化の問題とは思えません。しかし、そこから配送先の顧客を簡単に追跡できますが、このモデルでは、配送先の住所や旅程を追跡できるかどうかは明確ではありません。