1

編集1：テーブルとそれらの関係の名前を変更して、質問を解決しようとしました。EDIT2：3つのDBテーブルに保持しているデータの種類を見ないでください。それらはその場で構成されました。それらは私の現実世界のシナリオではありません（そして、いいえ、私は私の現実世界のデータについて話すことができません..実際、それは現在1人の親と6人の子供です）。データの種類を無視して、いくつかのデータが必要であるという事実を確認してください。EDIT3：2つのFKは0または1対1の関係です。0から多くではありません。1対1ではありません。0または1対1の関係と1対1の関係を避けようとしているので、外部結合は必要ありませんが、内部結合が必要です。

質問：提案されたデータベース設計が良い/悪い/ラメなどであるかどうかを知る必要があります。

問題：今日、インデックス付きビューを作成しようとしましたが、テーブルに外部結合があるために失敗しました。はぁ。だから私はこれを次のデザインのように修正できるかどうか疑問に思っていました：

  • 3つのテーブル。
  • table_Userはtable_AddressにFKを持っています
  • table_Userはtable_VehicleにFKを持っています
  • 等..

テーブルBとC（現在はルックアップテーブルのように機能します）があります。

  • Id INT IDENTITY PK
  • 説明NVARCHAR（100）NULLABLE

null許容型に気づきましたか？このように、table_Userの何かがtable_Addressに存在しません...フィールドはnullです（内部結合のため）。

以前、LEFT OUTER JOINを作成したので、table_bにデータがない場合は、各フィールドの結果がnullになります。

ここにいくつかのデータ例を投げます...

Table_User

  • ID：1、名前：フレッド、アドレスID：1（NULL）
  • ID：2、名前：ジョー、住所ID：2（1スミスストリート.....）
  • ID：3、名前：ジェーン、住所ID：2（1スミスストリート.....）

Table_Address

  • ID：1、説明= NULL
  • ID：2、説明=1スミスストリート

等

それで、私はついにこれをすべてインデックス付きビューに入れることができます。（私の実際のシナリオには約8つのテーブルがあります）。

注：DBはMicrosoft Sql Server 2008ですが、これはどのDBにも当てはまります。

Q1：そのデザインは大丈夫ですか？

Q2：では、ここで行っているのは、データを正規化することですよね？内部結合を一緒に保つことによって。

Q3：最後に、これで問題がない場合は、一意の制約、キー、インデックスなどを使用して、テーブル内のデータ（住所など）が一意であることを確認することもできますか（わかりません）。適切な用語の）。

達人に感謝します！

4

4 に答える 4

5

あなたの質問は紛らわしいと思いますが、多分私は少し助けることができます。

まず第一に、テーブルには結合がなく、クエリには結合があります。別のテーブルへの結合を使用してテーブルを作成することはありません。関連する可能性のあるテーブルは2つだけであり、結合を使用してそれらのテーブルをクエリできます。

dbの正規化について読むことをお勧めします。ウィキペディアには素晴らしい記事があります：http：//en.wikipedia.org/wiki/Database_normalization

あなたの現在のケースについて、私はあなたが何をしようとしているのかわかりません。そのアドレスが異なる行で繰り返されている場合、アドレスのIDを持っていても問題ないようです。ただし、いくつかの「アドレステーブル」が必要なのは奇妙に思えます。設計時に覚えておくべき最も重要なことは次のとおりです。-すべてのテーブルに正しい主キーを設定して、テーブルを正しく結合できるようにします。-非常に正当な理由がない限り、データを繰り返さないでください。しかし、私は再び前の記事をお勧めします。

お役に立てば幸いです。:)

于 2008-11-26T08:08:35.993 に答える
1

非常に紛らわしい質問なので、データベースの正規化を調べてください。3番目の正規形（英語ではそのように呼ばれることを願っています）は、ほとんどの問題を解決するはずです。

クイックヒント：繰り返されるデータがある場合は、外部キーを介して最初のテーブルで参照する別のテーブルが必要です。他のすべては単なるクエリです。

于 2008-11-26T08:21:10.370 に答える
0

つまり、基本的に、Aと同じ行数にするために、テーブルBとCに偽のレコードを追加しているのでしょうか。データセットが大きい場合は、実際に必要とせずに行数を増やし、不整合のリスクを冒しているため、私があなたである場合はそれを行いません（レイアウトは、これらの偽のレコードが挿入されました）。それとは別に、インデックス付きビューで何を達成したいですか？パフォーマンスの向上？使用しているDBMSを記述していませんが、MSSQLでの私の経験から、テーブルA、B、およびCに適切なインデックスがあれば、サーバーが使用できるため、これは大きなメリットにはなりません。インデックス付きのビューがなくても、優れたクエリプランを構築できます。

于 2008-11-26T08:43:49.043 に答える
0

個人的には、このデザインには「いいえ」と言います。理由:

  • (当てはまらない場合があります) アドレス フィールドを正規化したままにしようとするということは、意図しない重複を避けるためにこのフィールドを処理する必要があることを意味します。つまり、ユーザーが正しい形式で住所を入力していることを確認する必要があります (そうでない場合、'1 mystreet' は '1, mystreet' などと入力することもできます。重複を避けるためにこれを確認する必要があります。そうしないと、正規化は何の役にも立ちません)。
  • 正規化する理由を見つけたとしても（つまり、アドレス用に別のテーブルを保持する）、「ダミー」アドレスの概念は私には奇妙です。null 許容の FK リレーションシップを使用しないでください。つまり、ダミーの ID をそこに置くのではなく、親ユーザー テーブルに NULL アドレス ID を格納します。
于 2008-11-26T10:52:08.067 に答える