A7Mの日記: たったひとつの冴えたやりかた
昨日に続いてちとむかついたので、毒を吐いてみるwwwww
OracleやAccessなどのRDBで属性マスターの類はキーと値の組み合わせで、そんなテーブルが複数個あるが普通だと思うけど、今やっている案件の属性マスターはデータ構造が斜め上。
CREATE TABLE文で表現するとこんな感じ。
CREATE TABLE MASTER_TABLE (
ID INT,
PARENT_ID INT,
VALUE_ORDER INT,
VALUE VARCHAR(256)
);
一見、なんの変哲もないテーブルなんだけれど、この案件の属性マスターはこの一つだけ。
このMASTER_TABLEに全ての属性ID(キー)とそれに対する値が突っ込んである。当然、インデックスも無い。
で、PARENT_IDが同じ値を持つものが同士が同一グループに属しているという設定。
これくらいまでは、納得できなくはない。
でも、値の取り出し方がちと異常。
例えば、ある属性の値一覧が欲しいと思ったら、テーブル情報テーブルとフィールド情報テーブルから属性グループ名を取り出し、 MASTER_TABLEのVALUEに検索をかける。
SELECT ID FROM MASTER_TABLE WHERE VALUE='hoge'
で、これで拾ったIDをキーに再度MASTER_TABLEから値一覧を拾ってくる。
SELECT VALUE FROM MASTER_TABLE WHERE PARENT_ID=:ID ORDER BY VALUE_ORDER
本当は、もっと複雑な手順だけど、こんな仕組みになっていることに気づくのに、今日一日かかってしまった。ヽ(`Д´)ノ ウワァァァン
テーブル仕様書の類は全然役に立たないし。結局、似た部分を処理しているコードをハックしてようやく気がついた。
で、帰り際にMyボスが、おいらに向かって一言。
「A7M君、今日、大分いらついていたね。だって、独り言多すぎるんだもの。(・∀・)ニヤニヤ」
たったひとつの冴えたやりかた More ログイン