0

私は mysql の初心者です。データベースの設計についてお聞きしたいのですが、私の設計を添付します (画像の投稿を妨げて申し訳ありません)。データベースを入力します。どちらが優れているか、またその理由を教えてください。または、この種のデータベースにはより優れた設計がありますか??

最初のデザイン:

tbl_member:
- id
- name

tbl_member_parent:
- id
- id_member
- parents_name

tbl_member_sibling:
- id
- id_member
- sibling_name

または 2 番目の設計:

tbl_member:
- id
- name

tbl_relation_type:
- id
- relation:"parent","sibling" 

tbl_member_relation:
- id
- id_member
- id_relation_type
- name_value

おそらく次は、relation_type (友人、隣人など) に (10-20) 行を追加します。

私の意見では、2番目を使用する必要がありますが、よくわかりません..笑

私の英語が悪い場合は申し訳ありません..

ありがとう..

@inhan
ic2 ..ええ、私もそう思います..これ
が私のミニデータベースデザインです..

オリジナル：

性別テーブル
- id INT auto_increment PK
- 性別 varchar : "male","female"

ステータス テーブル:
- id INT auto_increment PK
- ステータス varchar :"active","notActive","problem"

権限テーブル:
- ID INT 自動インクリメント PK
- 権限 varchar:"manager","moderator","member"

国テーブル:
- id INT auto_increment PK
- 国 varchar

都市テーブル:
- id INT auto_increment PK
- 都市 varchar
- id_country INT、FK (to country table.id)

ジョブ テーブル:
- id INT auto_increment PK
- ジョブ varchar

member table:
- id INT auto_increment PK
- member_name varchar -birthdate
date
- id_sex INT、FK (性別 table.id へ)
- id_status INT、FK (status table.id へ)
- id_privilige INT、FK (特権 table.id へ)
- address varchar
- id_city INT、FK (to city table.id)

なぜなら、人々は複数のニックネーム、兄弟、友人、職業、国籍などを持つことができるからです.

memberJob テーブル:
- id INT auto_increment PK
- id_member INT、FK (メンバー table.id へ)
- id_job INT、FK (ジョブ table.id へ)

memberNationality テーブル:
- id INT auto_increment PK
- id_member INT、FK (メンバー table.id へ)
- id_country INT、FK (国 table.id へ)

次に memberNickname テーブルを作成します。memberSiblings テーブル。memberFriendsテーブルなど

memberJob のテーブル デザインを変更したい。メンバー国籍;メンバー兄弟; メンバーフレンズ

私はこのようにすると思います：

関係テーブル
- id INT auto_increment PK
- 関係タイプ varchar : "siblings", "freinds", "job", "nationality",

memberDetail
- id INT auto_increment PK
- id_member INT、FK (メンバー table.id へ)
- id_relation INT、FK (関係 table.id へ)
- id_value INT、FK (id_relation の場合: sibling と friends id_value メンバー table.id への FK) ; if id_relation:job then id_value FK to job table.id; if id_relation:nationality then id_value FK to country table.id)

memberNickname
- id INT PK auto_increment
- id_member INT FK (メンバー table.id へ)
- ニックネーム varchar

それって何かまずいことありますか？？

4

1 に答える 1

0

members次の列を持つ単一のテーブルで十分です。

  • idINT auto_increment PK
  • name
  • parent_idINT デフォルト NULL、FK (to id)

したがって、クエリを実行するときは、同じテーブルを使用して結合するだけです。ないものはparent_id最上位レベルのメンバーになり、その他は子になります。兄弟を見つけるには、同じ親を指している子を見つけるだけです。

[編集1]

別の種類のリレーションシップが必要な場合は、他の 2 つのテーブルを作成parent_idし、上記のテーブルの列を無視できます。

relationshipTypesテーブル

  • idINT auto_increment PK
  • rel_name

およびrelationships表:

  • idINT PK
  • user_idINT、FK (へmembers.id)
  • rel_type_idINT、FK (へrelationshipTypes.id)

からユーザーを選択し、members一致するすべてのレコードを で検索し、それをrelationships結合して、relationshipTypesすべての情報を取得できます。

【OPコメント】

以下の発言は私の個人的な考えです。

  1. 各メンバーは 1 つの性別 (性別)、1 つのステータス、および 1 つの特権のみを持つことができ、そのすべてをテーブルに列挙することができるため ( 、技術的に言えば)、sex、status、テーブルは不要です。privilegeENUMmember
  2. また、複数の国籍を忘れて、ユーザーに 1 つの国籍を選択させるだけです。したがって、このデータもテーブルに移動できmemberます。
  3. toテーブルの FK を保持しながら、テーブルにcityデータを(VARCHAR として) 保持します。この情報が得られる可能性は非常に高いため、現実的ではないように見えます。システムで、特定の国 (ターゲット市場) に焦点を当てたい場合は、その国の都市リストを列挙した列に加えて、「その他」のオプションを作成し、その「その他」の都市の追加の列を作成できます。これは datatype にすることができます。membercountrycountryVARCHAR
  4. ジョブの処理はあなた次第です。ビジュアルフォームをどのように見せたいのかわかりません。
于 2013-01-30T10:22:54.373 に答える