...定石とかそんなものを知らんから、なんだろか。
今書いてるお試しアプリでは、ポリモーフィックな木構造を扱います。
class 部品; // 森羅万象のルート
class 基板 : 部品; // 基板(部品の集合)もまた部品なり
class 抵抗 : 部品; // 抵抗値をメンバに持つ
class コンデンサ : 部品; // キャパシタンスをメンバに持つ
class コイル : 部品; // インダクタンスをメンバに持つ
こんなカンジのクラス群。これのインスタンスを使って:
製品 は 基板1 から構成される
基板1 は 抵抗1, 抵抗2, 基板2, 基板3 から構成される
基板2 は 抵抗3, コイル1 から構成される
基板3 は コイル2, コンデンサ1 から構成される
なんてな木構造を構築するっす。
で、こいつをDBに書いたり/DBから読んだり せぇと。
こんなとき、クラスごとのテーブル作るんですよね。
基板table ( ID TEXT, タテ幅 INTEGER, ヨコ幅 INTEGER)
抵抗table ( ID TEXT, 抵抗値 INTEGER)
コンデンサtable ( ID TEXT, キャパシタンス INTEGER)
コイルtable ( ID TEXT, インダクタンス INTEGER)
みたいな。 # [1] ここまであってる?
で、製品を構成する要素をテーブルにすると
構成要素table (
ID TEXT, ← 部品のID
PARENT TEXT ← その部品が乗ってる部品。なければNULL
)
これで製品を構成する全要素を構成要素tableに載せられます
# [2] ここまであってる?
製品:
(基板1, NULL)
(基板2, 基板1)
(抵抗1, 基板2)
(抵抗2, 基板2)
...
この製品を構成する抵抗1の抵抗値が知りたいとき、
SELECT 抵抗値 FROM 抵抗table WHERE ID=抵抗1
なのかな。
# [3] ここまであってる?
でもね、「抵抗tableを検索すればいい」ってこと、つまり
部品のクラスを示す"型コード"を構成要素tableのカラムに
置かにゃならんですよね。
# [4] ここまであってる?
だとすると"型コード"から"対応するテーブル名"を導出できにゃ
あかんですよね?
# [5] ここまであってる?
[6] そう、コードの中では仮想関数でやってたよなことです。
それをDB上にマップするのってどぉやんです?