0

パフォーマンスの観点から、この質問を拡大したいと思います。データベーススキーマは次のとおりです。

作る

  • MakeId
  • MakeName

モデル

  • モデル ID
  • モデル名
  • MakeId (外部キー)

車両

  • 車両 ID
  • 購入日
  • モデル ID (外部キー)

車両のメーカーを知りたい場合は、Vehicle.Model.Makeを使用して Model テーブルをトラバースする必要があります。このように接続された 3 つではなく 4 つまたは 5 つのテーブルがあると仮定して、たとえば InvoiceForVehicle.Vehicle.Model.Make と記述する必要があります。これにより、クエリのパフォーマンスが低下すると思います。

MakeId (FK)列を InvoiceForVehicle テーブルに追加して、make に直接渡すことができます。これは、データが重複していることを意味し、InvoiceForVehicle と車両の間の関係を変更するたびに、それに応じてMakeId (FK)を更新する必要があります。

車両の請求書

  • 請求書ID
  • 作成日
  • 車両 ID (外部キー)
  • MakeId (外部キー)

それは良い考えですか？

4

2 に答える 2

1

ID で参照し、実際の検索は行わないため、(もしあったとしても) 多くのヒットが表示されるとは思えません。

（私の知識に基づいて）既存のモデルは、新しく提案されたソリューションよりも正しく構造化されていると思います。新しいソリューションのように、データの整合性が失われるような状況に身を置くべきではありません。

だからあなたの質問に答えるために。いいえ、新しいアイデアは良い解決策ではないと思います。データベースの正規形に基づいて、既存の設定はより「正しい」ものになります。また、Entity Frameworkデータを遅延ロードするため、不要なクエリを実際に実行することはありません。

于 2012-12-12T20:47:15.913 に答える
1

パフォーマンス上の理由:たぶん

一貫性の理由:いいえ

あなたが提案したものを使用すると、その車両（のモデル）に対応していないメーカーに接続された車両を持つことが可能になります！

対応する複合外部キーを使用して、複合 (およびおそらく自然) キーをずっと下まで使用することを試みることができます。この場合の重要な外部キーは、 からVehicle (MakeId, ModelId)への外部キーになりModel (MakeId, ModelId)ます。

于 2012-12-12T20:49:17.017 に答える