2013-04-10 21 views
8

テーブル内の外部キーの適切な処理を検証する必要があります。ここに私の2つのテーブルが作成されています。私はそれがnullになりたいので、人が記載されているアドレスを持っていない可能性があります。さもなければ、私はアドレステーブルからプライマリキーを参照し、それを外部キーとしてPersonテーブルに格納したいと思います。人がいないアドレスオブジェクトを持っている可能性もあります。人のための外部キーを使用したSQL Serverテーブルの作成

表:アドレス用

CREATE TABLE Person 
(
    PersonID int IDENTITY PRIMARY KEY, 
    FName varchar(50) NULL, 
    MI char(1) NULL, 
    LName varchar(50) NULL, 
    AddressID int FOREIGN KEY REFERENCES Address(AddressID) NULL, 
) 

表:私は、トリガーで働いたことはないが、私は挿入を処理する方法を用いることであろうと想定しています

CREATE TABLE Address 
(
    AddressID int IDENTITY PRIMARY KEY, 
    Street varchar(60) NULL, 
    City varchar(50) NULL, 
    State varchar(2) NULL, 
    Zip varchar(10)NULL, 
    Intersection1 varchar(60) NULL, 
    Intersection2 varchar(60) NULL, 
) 

またQ2最初にアドレスを挿入し、プライマリキーを取得し、それをストアドプロシージャに渡してPersonテーブルに挿入するストアドプロシージャ?

+1

「アドレス」は最初に作成する必要がありますが、私にとってはうまく見えます。 –

+0

このデザインが必要なのは確実ですか?何人の人が同じ住所を持っていますか?これは、外部キーをアドレステーブルから削除する唯一の理由です。それ以外の場合は、アドレステーブルでPersonIDをPKとして使用してください。 –

+1

@ElectricLlamaに同意します。あなたはデザインを検討したいかもしれません。あなたは通常、PersonIDをAddressテーブルに置き、Personテーブルでそれを参照します。実際には、人は複数のアドレスを持つことができます。 – Elmer

答えて

4

質問があります:複数の人同じ住所に住んでいますか?また、1人の人が複数の住所に住んでいる可能性はありますか?

この場合、追加のPersonAddressテーブルとのM:Nの関係を考慮してください。

そうでない場合は、「人がいない人が住所や住所がない人がいる可能性は高いですか」と自分自身に問いかけます。アドレステーブルを持つPersonID?

1

私はこのようなアドレスを変更します:あなたが指定したStreetAddress、市と郵便番号、 で人を追加した場合、その後、あなたがSavePersonストアドプロシージャでこれを行うことができますので、私はこれを行うだろう

CREATE TABLE Address 
(
    AddressID int IDENTITY, 
    Street varchar(60) NULL, 
    City varchar(50) NULL, 
    State varchar(2) NULL, 
    Zip varchar(10)NULL, 
    Intersection1 varchar(60) NULL, 
    Intersection2 varchar(60) NULL, 
) 
Alter Table Address Add Constraint 
PK_Addresses Primary Key Clustered 
(City Asc, Zip Asc, Street asc) 

Create Unique NonClustered Index IX_Address_Key 
On Address{AddressId) 

If Exists (Select * From Address 
      Where Street = @Street 
       And City = @city 
       And Zip = @zip) 
    Begin 
     Select @AddressId = AddressId 
     From Address 
     Where Street = @Street 
      And City = @city 
      And Zip = @zip 
    End 
Else Begin 
     Insert Address(Street, City, State, Zip) 
     Values(@street, @city, @state, @zip) 
     Set @AddressId = Scope_Identity() 
    End 

そして、t-sql変数@AddressIdの値をPersonテーブルに挿入します。他のSQLステートメントの結合には引き続きAddressIdを使用しますが、アドレステーブルに重複アドレスを挿入できないようにするCity、Zip、Streetアドレスの主キーがあります。これをクラスタ化インデックスにすると、すべてが1つのジップにあるアドレスのグループを取得または処理する必要がある場合があります。

+0

私は申し訳ありませんが、これらの変更を行う際には何のメリットもありません。実際には、同じ時間にPKではないアイデンティティ列を持つ - まず、私はそのような考えを聞いています。 SPで言及されているものはどれも元のデザインと同じように行うことができ、City、Street、Zipカラムで一意性が必要な場合は、ユニークな制約で行うことができます。また、テーブルアドレスはAddressID(PersonとJoinのアドレスを見つける)、City、State、Zipによってブラウズされ、クラスタード・インデックスの候補としてはるかに優れています。 PS:null可能な列にPKを持たせることもできません。 –

関連する問題