0

エンティティ、テーブル、および外部キーを理解しようとしています。私は次のものを持っています： -

AnObject - これはエンティティ タイプであると特定しました。

ID (Primary Key)    
Description    
State    
DependsOn    
Creator

現在、State には 2 つの値しかありません[Alive, Dead]。ただし、将来的には別のものになる可能性があります。ただし、どちらか一方しかあり得ませんが、2 つの間で変わる可能性があります。

質問：

State は独自のエンティティ タイプにする必要がありますか? それはエンティティ型ですか、それとも単なるテーブルですか? State は AnObject への外部キーを持つべきですか、それともその逆ですか? 例えば

州

ID (PK)
Description
AnObject_ID (Foreign Key references AnObject)

質問: AnObject の DependsOn 属性は、他の AnObject エンティティ タイプの複数の値を持つことができます。明らかに、フィールドに複数の値を設定することはできませんが、これをモデル化する方法がわかりません。

AnObject の Creator 属性も、厳密な数の値を使用します [Fred、Jim、Dean]。AnObject ID への外部キーを持つ Creator のエンティティ タイプ (テーブル) を用意する必要がありますか? つまり、A Creator は、0、1、m の AnObjects を作成できますが、AnObject は作成者を 1 人しか持てませんか?

ありがとう、

4

2 に答える 2

0

ユーザーがユーザーインターフェイスを介して他の状態値を追加できるようにする必要がない限り、状態は単なるenumフィールドである可能性があります。その場合、提案したようにルックアップテーブル (1 対多の関係) を使用できます。使用しているデータベースはわかりませんがenum、MySQL のタイプに関する情報は次のとおりです: http://dev.mysql.com/doc/refman/5.6/en/enum.html。

ルックアップ テーブルを使用する場合、AnObject には、State テーブル内の目的の行を指す StateID というフィールドが必要です。

DependsOn は多対多の関係のようです。そのためには、結合テーブルが必要です。

Table: Dependencies

Primary key (called a "composite key" because it's made up of more than one field):
    AnObjectParentID
    AnObjectChildID

親子関係には依存関係が必要であると想定しましたが、そうでない場合は、テーブルまたはフィールドに別の名前を付けることをお勧めします。

于 2013-02-24T16:38:25.507 に答える
0

AnObject からの外部キーを使用して、列挙値のテーブルを追加できます。状態は、null ではない varchar 型の単一フィールドとして表すのがおそらく最適です。テーブルの主キーを varchar フィールドにすることができます。int 型である必要はありません。

これにより値が制限されますが、合理的な構文を使用してクエリを実行できます (つまり、WHERE state = 'Alive' (ただし、この場合、物事を時期尚早に抽象化していると思いますが、単純に保ち、単純な bool を使用します)列 IsDead)。

DependsOn は一方向の属性です (おそらく、A を B に依存させ、B を A に依存させることはできません)。ここでの本当の問題は、これらのアイテムをクエリする方法と、それらのアイテムがいくつあるかということです。依存関係のチェーン全体を一度に引き出したいが、そのチェーンが長い場合、それを行うために何百もの個別のクエリを実行することは避けたいと考えています。あなたのユースケースは何ですか？

于 2013-02-24T16:42:59.900 に答える