2009-04-05 9 views
1

まず、この質問のフィードバックの性質について申し訳なく思っています。私はできるだけ一般化するようにしていますので、他の人も同様に得ることができますが、私はこのデザインについてフィードバックをする人がいないので、皆さんが私を助けてくれることを願っています。リレーショナルデータベースで異なるユーザータイプをモデリングする

私のデータベースでは、異なるユーザータイプをモデル化することはできません。私は共有するusertypesの資格情報を持っていると思います。この問題は、基本的に継承に関するものです。これは、RDBがあまりうまくやっていないことです。

しかし私は、このデザインを思いついた: DB design http://img48.imageshack.us/img48/9196/dbdesign.png

を..しかし、私はそれに満足しなければならない場合、私はわかりませんよ。私がそれについて好きではないのは、ビジネス契約の量です。まず第一に、どのユーザータイプが特定の資格情報に属しているのかわかりません。つまり、N個のテーブルを検索する必要があります.Nは、取得したユーザータイプの数です。したがって、私は、ユーザーのタイプを自分の役割と結びつけることを考えました。したがって、資格情報Aを持つユーザーが "UserType1"と "UserType2"の役割を持っていれば、UserType1には戸惑いがあります。彼または彼女を表すUserType2テーブル。 - これらの "ビジネスロジック"の制約が気に入っているかどうかは分かりません:)

このデザインに関するフィードバックは、他のデザインと同様に非常に高く評価されます。事前

答えて

4

おかげで、それはOOで抽象クラスに類似だ場合は、親に識別子列を置くことができます。 discriminatorは、各子タイプごとに異なる値を持ちます。あなたが巧みな人なら、それは子供のタイプごとに1つの行を持つテーブルへのfkです。

または、usertype1へのauthcredentialsの結合が、他のどのタイプのusertype1でも成功し、他の子タイプではなく、他のテーブルと同様に成功することに頼ることができます。各子テーブルへの左外部結合では、型のすべての列(特にid)はNULLであり、そのIDはnullではありません。その後、これに基づいて算出列を追加することができます。

select 
a.*, b.*, c.*, 
case when b.id is not null then 1 else 0 end as is_usertype1, 
case when c.id is not null then 1 else 0 end as is_usertype2, 
from authcredentials a 
left outer join usertype1 b on (a.id = b.authcredential_id) 
left outer join usertype2 c on (a.id = c.authcredential_id); 

が続いているが、使いやすさのためのビューを選択します。挿入物はまだ別のテーブルのusertypeとusertype2にありますが、オブジェクト指向プログラミングでは、継承されず、共通ベースの2つのサブクラスには必ずしも同様の継承元がありません。

基本クラスが派生クラスの前に構築されているのと同じように、子行を作成する前に親行を作成する必要があります(FKが必要です)。

postgresqlは、このように明示的にテーブルの継承をサポートしています。 Hibernate ORMはテーブルをJavaサブクラスにマッピングするためにこれをサポートしています。

関連する問題