提示されたサンプルからは、
共通性・継承性という点がしっくりきませんでしたが、
上記のような例では関係(リレーション)自体をテーブル化するのがよくあるパターンかなと思います。
###関係のテーブル化
人脈という言葉はいろんな関係性をぼんやりさせてしまうので、
**「両親」とか、「友人」**という関係自体をテーブル化すると、
多少のパフォーマンスは犠牲となりますが、融通が大分利きやすくなります。
更に言うと個人情報みたいなのをマスタテーブル化するとよりすっきりするでしょう。
以下はそれぞれのモデル例です。
個人情報
ID (主キー)
名前
年齢
両親(両親.IDへの外部キー)
SQL
1両親
2 ID(主キー)
3 父親(個人情報.IDへの外部キー)
4 母親(個人情報.IDへの外部キー)
5 一意キー(父親、母親)
友人
個人ID(個人情報.IDへの外部キー)
友人(個人情報.IDへの外部キー)
主キー(個人ID, 友人)
このように分けると、
データベース特有の問題である更新時不整合などの問題も抑制できますので、
そういう意味でも分けると良いかなと思います。
(**「正規化 更新時不整合」**などで調べるとより詳しい情報が得られると思います。)
ちなみに上のようにテーブルを分けた場合、父親が同一の人物を得たい時は、下記のようなクエリで取得できます。
SQL
1SELECT
2 個人情報.*
3FROM
4 個人情報
5 INNER JOIN 両親
6 ON 個人情報.両親 = 両親.ID
7WHERE
8 両親.父親 = 'bob'
###共通性・継承性の表現方法について
一応データベース設計においても、
それらを表現するための技法はあります。
概念データモデリングでよく登場する用語ですが、スーパータイプ、サブタイプというで調べてみると有益な情報が得られるかもしれません。
(基底クラス、派生クラスとかとイメージが近い)
1つ例を挙げますと、
大きく「会員」という括りがあり会員の中でも「一時会員」「特別会員」があるという時。
「会員」がスーパータイプ、「一時会員」と「特別会員」をサブタイプとした簡単なテーブル構成を以下に記載します。
(サンプルの構成は単純なのであまり分けるメリット感じられないかもしれませんが)
SQL
1-- 会員タイプ全てに共通する属性はここで定義
2会員
3 会員ID(主キー)
4 会員タイプ -- 「1:一時」「2:特別」
5 会員登録日
SQL
1-- 一時会員固有の属性を定義
2一時会員
3 会員ID(主キー)
4 有効期限
SQL
1-- 特別会員固有の属性を定義
2特別会員
3 会員ID(主キー)
4 付与ポイント残
5 最終ポイント利用日
このようにテーブルを分けることで、
「一時会員」、「特別会員」をテーブル自体で分類して管理できるというメリットがあります。
尚、上記の構成だと共通情報を含んで一時会員を検索する場合は以下のイメージとなります。
SQL
1-- 有効期限切れの一時会員を取得
2SELECT
3 会員.*
4, 一時会員.有効期限
5FROM
6 会員
7 INNER JOIN 一時会員
8 ON 会員.会員ID = 一時会員.会員ID
9 AND 会員.会員タイプ = '1'
10WHERE
11 一時会員.有効期限 < 現在日
###追記
パラメータが動的に変わるという部分を見逃してました^^;
データベースのテーブルでは、
カラム(各種パラメタ値)を動的に増やすのはNGですし、
1つのカラムにはパラメタを連結して登録するのもオススメはできません。
(アンチパターンに記載されるレベルには推奨されてません。)
データベースによってはカラムを配列型として定義できるとものもありますが、
ベンダ依存となるのでこれを利用するのもあまりオススメできません。
なので動的にパラメタが変化する場合は、
パラメタを管理するテーブルを作るのが無難な気がします。
(俗に言う「マルチカラムアトリビュート」対策です)
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/08/31 02:41
2016/08/31 03:32
2016/08/31 04:02
2016/08/31 13:03
2016/09/07 15:40