2016-05-29 12 views
1

こんにちは私はウェブサイトで働いてフラスコを学んでいて、私は理解できないような問題に遭遇しました。3つのテーブルで1対多に接続していますか?

プライマリキーを介して接続する1対多のテーブルを作ってみたいと思います。アイデアは、ユーザーがキャラクターを作成できるということです。タイプがオリジナルの場合は、元のテーブルを表示し、IDに基づいてキャラクターを表示できます。

私の質問です:これは可能ですか?もしそうなら、私はこのようにするか、IDの代わりに文字を作成した人に基づいて接続する必要がありますか?

Diagram

+0

あなたはすでに回答を受け入れていますが(私が選択したオプションとその理由を知りたいのですが)、「結合テーブル継承」(http://docs.sqlalchemy。 org/en/latest/orm/inheritance.html#joined-table-inheritance)を使用します。 – van

+0

ご意見ありがとうございます。私はラベルの*結合されたテーブルの継承を知らなかった*。これは私の答えで可能性2で達成できることに同意しますか? – saq7

+0

私はPossibility 3を試してみたいと思っていましたが、Joined Table Inheritanceも見ていきます!ありがとうございました。 – geminateCoder

答えて

0

が、このことは可能ですし、私はそれをこのようにやって行くか、または必要がありそうだとすれば 作成者に基づいてそれらを接続する:

この

は私がやろうと考え何の図です。文字の代わりに id?

作成者に基づいて接続することもできます。

データの種類や達成しようとしている内容によっては、さまざまな可能性があります。私はあなたがビューを作成することができますし、それは3つのすべての加入を持つ3

以下の可能性1

をリストアップ。 Fandomテーブルだけで参照される文字レコードがある場合、ビューは元のテーブルとDungeonテーブルの列をnullにします。ここでの問題は、それは確かに一つだけになり、制約を施行するために、データベースに難しいだろうということになるだろう単一記録

CharacterView 
- Character.id - is not null 
- Character.creator - is not null 
- Character.field1 - is not null 
- Character.fieldN - is not null 
- Original.id - is null 
- Original.field1 - is null 
- Original.fieldN - is null 
- Fandom.id - is not null 
- Fandom.field1 - is not null 
- Fandom.fieldN - is not null 
- Dungeon.id - is null 
- Dungeon.field1 - is null 
- Dungeon.fieldN - is null 

のために、このようなビットになります

3つのテーブルは任意の単一の文字レコードを参照します。この制約をアプリケーションで実行する必要があります。

可能性2

テーブルを別々に設定することもできます。文字テーブルを参照する3つのテーブルがすべて同じフィールドを持つ場合、それらを1つのテーブルに結合し、可能な値があるタイプフィールド(オリジナル、Fandom、Dungeon)を持つことができます。

Combined Table 
- id 
- commonField1 
- commonFieldN 
- Type (possible choices: Original, Fandom, Dungeon) 

可能性3

これらのテーブルは、まったく同じフィールドを持っていない場合は、あなたが一方のエンティティを構成するために複数のレコードを使用することができます。例えば、

TableA 
- id 
- field1 
- field2 
- field3 

TableB 
- id 
- field4 
- field5 
- field6 

上記のテーブルAとBを元のテーブル、Fandomテーブル、Dungeonテーブルに置き換えて、1つのテーブルに置き換えることができます。以下に示す

TableC 
- id 
- entity_id (shared among all the records that make up one entity) 
- char_id 
- field_name (possible values field1, field2, ..., field6) 
- value 

いずれの場合でも、名前などの作成者の詳細は、他のすべてのテーブルの参照で独自のテーブルにある必要があります。そのデータは、現在のようにすべてのテーブルで繰り返されるべきではありません。

関連する問題