2

多数の多対多の関係を持つスキーマがあり、私が見ているのは、さまざまな名前のテーブルに散らばっている類似のデータ構造がたくさんあることです。私が持っている直感は、同じ結果を達成するためのより効率的/望ましい方法があるということですが、どの代替アプローチが合理的な設計/ベストプラクティスに該当するかはわかりません.

注: 国、TrafficTypes、People (現在存在するもの) はすべて Id 列と Name 列で表すことができますが、将来的には追加のフィールドを持つ可能性があります。多分私が求めているのは、継承に似たある種のテクニックですか？

これが私が持っているものの図です：

ここに画像の説明を入力

4

4 に答える 4

4

似ていると思うものをひとまとめにしないでください。後で各エンティティに関する詳細情報を保存する必要があるときに、それらは分岐する可能性があります。

データベースにあるテーブルの数に問題がありますか？

あなたはおそらくオブジェクト指向の設計位置から問題について考えており、ある種の「親」テーブルを使用して一般的な部分を表すことができると考えています。データベースはそのようには機能しません。

注意しないと、MUCKまたはOTLTテーブルになってしまいます。

于 2012-09-21T19:54:03.157 に答える
2

すぐに、私は別々のエンティティ/オブジェクト/（車と動物）を別々のテーブルに保管します。

そのようなエンティティがプロパティをオーバーラップする可能性は、せいぜいわずかです。

つまり、これらのエンティティがシステム内で進化し始めると、1つのテーブルに数百の列があり、エンティティごとに1つが入力されていることがわかります。

于 2012-09-21T19:55:14.010 に答える
1

心配しないで。あなたはそれを正しくやっています。

高度に正規化されたスキーマでは、ほぼ同一のテーブルが大量に存在することになります。

他の人が言ったように、あなたが検討し始めているもの (複数のものの一般的なテーブル) は非常に悪い考えであり、多くの欠点があります。

最大の欠点は、データの整合性を維持するという点で、関係が役に立たなくなることです。だれかが、TrafficTypeId があるべき場所に CountryCode を割り当てることなどを妨げるものは何もありません。

もう 1 つの欠点は、大きなテーブルを 1 つ持つと、多くの小さな特殊なテーブルよりもパフォーマンスが低下する可能性があることです。余分な不必要なブロッキングが原因です。

ある種の継承の概念を実装したい場合もありますが、それはデータベースにアクセスするコードで行うのが最善です。

于 2012-09-21T21:29:47.120 に答える
1

継承があなたのケースにどのように適用されるかわかりません。ただし、SQL テーブルやリレーションに適用される継承に関心がある場合は、以下を参照してください。

ER モデリングのレベルでは、「ER モデルの専門化」を参照してください。これは、拡張 ER モデル ダイアグラムが「is A」関係を表す方法です。

テーブル設計のレベルでは、「クラス テーブルの継承」と「共有主キー」を調べて、一緒に使用すると、OOP で継承が行うことを模倣するいくつかの手法を探します。「単一テーブルの継承」を調べて、よりシンプルで無駄が多い代替案を探すこともできます。

于 2012-09-21T20:09:02.873 に答える