2011-12-11 13 views
1

私はシンプルなアドレス帳タイプのデータベースを持っています。私はおそらく過大化してしまったでしょうが、それは学習するほどの生産性についてです。SQL:共通データを除外

私はID(生成された身元)、姓/名、タイトルなどを持つPEOPLEテーブルを持っています。また、独自のテーブルのIDフィールドには外部キー「配偶者」もあります。明らかに、null可能です。

私は、ID(生成された身元)とカタツムリメールに必要なすべての詳細を持つテーブルADDRESSESを持っています。

2つの外部キーを持つPERSONADDRESSという表があります。PERSONはPEOPLE.IDを指していて、ADDRESSはADDRESSES.IDを指しています。

理論的には、PEOPLEと電子メールの外部キーを持つEMAILSテーブルがあります。理論的には、人々(私のようなオタク)は複数の電子メールを持つことができます。将来の類似データ間の関係。 (PHONESなど)。

それで、問題はこれです。私はいくつかのアドレスラベルを作成したい。 (そう、クリスマスカードには少し遅れています)。Libreofficeにこれをさせるためには、LOがデータを読み込めるビューを作成する必要があると思います。

これはやや単純ですが、現時点では重複が多すぎます。私の見解は、次のような作成されます。

CREATE OR REPLACE VIEW ADDRBOOK.LABELS AS 
    WITH T AS (
    SELECT DISTINCT 
     P1.ID AS AID, 
     P1.TITLE AS ATITLE, P1.GIVENNAME AS AGIVEN, P1.LASTNAME AS ALAST, 
     P2.TITLE AS BTITLE, P2.GIVENNAME AS BGIVEN, P2.LASTNAME AS BLAST, 
     A.STREET, A.MUNICIPALITY, A.STATE, A.COUNTRY, A.POSTALCODE 
    FROM 
     ADDRBOOK.ADDRESSES A 
     JOIN 
     ADDRBOOK.PERSONADDR PA 
     ON PA.ADDRESS = A.ID 
     JOIN 
     ADDRBOOK.PEOPLE P1 
     ON PA.PERSON = P1.ID 
     LEFT OUTER JOIN 
     ADDRBOOK.PEOPLE P2 
     ON P1.SPOUSE = P2.ID 
    ORDER BY P1.ID 
) 
    SELECT DISTINCT 
    ATITLE, AGIVEN, ALAST, 
    BTITLE, BGIVEN, BLAST, 
    STREET, MUNICIPALITY, STATE, COUNTRY, POSTALCODE 
    FROM T 
; 

しかし、これは人物AとBが結婚しているならば、私はAがATITLE、所与の、ALASTの下に表示された一つのエントリを取得するつもりだ、とBであることを意味しますBTITLE、BGIVEN、BLAST、およびそれらが位置を逆転した別のエントリ。この区別は、単に異なる列にあるため明らかに機能しません。私はこの排除をするために必要な変更を想像するのが苦労しています。

この特定の問題の単純な解決策である、2人の人物の1人を切断すると、一般的なテーブルデータの概念に反して実行されることに注意してください。私はそれが必要なときに必要です。確かに、これは90%のラベルですが、学習の長所である限り、誰かが私をここで助けてくれることを願っています。

答えて

1

この句を一時テーブルクエリに追加します。これらのタイプのAB/BA問題のほぼすべては、同様の比較によって解決することができます。

WHERE P2.ID IS NULL OR P1.ID < P2.ID 
+0

すべてのケースで必ずしも必要な注文ではありませんが、IDなどの順序を逆にするなどの対応が必要です。ありがとう! – Tanktalus

+1

その他の考慮すべき点... head_of_householdフィールドが有用かもしれません。あなたが他のタイプの関係(配偶者、兄弟、親、子供、教会、クラブ会員など)を管理するためにこれを成長させるつもりなら、配偶者をPEOPLEから引き裂き、 RELATIONSHIPテーブル。 – phatfingers

関連する問題