データベース構造のアップデート

DBテーブルをちょっと変更しようと思う。
もうデータが入ってるんだけど
テーブル「プロダクト」にカラム「カテゴリ」を追加する。

構造のアップデート

今はこう。

    'product_data/@definition/brief' => 'プロダクト',
    'product_data/type' => 'database',
    'product_data/table' => 'product',
    'product_data/fields' => 'owner;project;caption;status;definition;docs;mods;budget;memo',
    'product_data/fields/definition/dataType' => 'note',
    'product_data/fields/memo/dataType' => 'note',
    'product_data/fields/status/options' => '0:planning;1:waiting;2:making;3:complete;-1:discard',

で、fieldsにcategoryを書き加える。

    'product_data/fields' => 'owner;project;caption;category;status;definition;docs;mods;budget;memo',
    'product_data/fields/category/options' => '1:project;2:document;3:product;4:person;5:location',

で、urlをコールしてアクションを実行する。
これでテーブルが作り直され、同じ名前のカラムのデータは引き継がれる。
元のテーブルはバックアップされる。

アクションにはこう定義してある。

'pms/scenario' => '/data/setup',
'data/setup/dataset' => 'product_data',

多分訳知りのエンジニアには”笑止”的なものかも。
「カラムの定義が何もないじゃん。インデックスは？」
みたいな。

でもプロトタイプなんか、ミニマムな情報で始めたいよね。
カラムフォーマットなんかは、ざっくり大体”なんでも入れば”いい。
つまりそれなりのサイズの文字型。

帰納的テーブル設計

パイロット運用してデータを貯めていって、そこから帰納的にテーブルフォーマットを設計した方が実情に合ってるし、”想定外”のバグをなくせる。

'product_data/fields/caption/size' => 64,
'product_data/fields/budget/dataType' => 'amount',
'product_data/fields/owner/index?' => true,

みたいに。

その参考にするためにデータをサマリするアクションがあるといい。

'pms/scenario' => '/data/summary',

各カラムに入ってるデータの最大サイズや型のヒントを出力する。

「こんな機能が必要なら作りゃいいじゃん」
とも思うだろう。
でもいちいち？
プロジェクト毎回作る？
これがフレームワークにあったら便利じゃないかな。

でも実際エンジニアにはどうでもいいことなんだよね。
人月で貰えるから、毎回同じ作業をしても別に構わない。
構うのは、経営者やクライアントなんだけどね。本当は。

ビューなら

ビューみたいなテーブルセットはこんな風に書く。

    'pbsset_data/@definition/brief' => 'PBS+プロダクト',
    'pbsset_data/type' => 'database',
    'pbsset_data/sources' => 'pbs;product',
    'pbsset_data/sources/pbs/data' => 'pbs_data',
    'pbsset_data/sources/product/data' => 'product_data',
    'pbsset_data/sources/product/relationType' => 'refer',

これでこんなSQLが裏でできる。

select t0.*, t1.*
from pbs t0
left join product t1 on t1.__id=t0.product
where ...

9割がたはこれで済む。
それでも複雑でとてもパラメータ化できない場合もあるだろう。
それならSQLを好きに書けばいい。

	'pbsset_data/sql' => <<<SQL
SELECT ... FROM ... LEFT JOIN ... ON ...
WHERE ...
SQL,

ただ複雑なSQLが必要てことは、テーブル構成は適正？と省みてもいいかも。

データ操作

データのCRUDは、こんな風。

'pms/scenario' => '/data/append',
'data/append/fields' => '追加するフィールド...',

'pms/scenario' => '/data/update',
'data/update/fields' => '更新するフィールド...',
'data/update/fields/更新フィールド1/value' => '更新フィールド1の値',
'data/update/where/fields' => '条件フィールド1;...',
'data/update/where/fields/条件フィールド1/value' => '条件フィールド1の値',

'pms/scenario' => '/data/delete',
'data/delete/primaryKey' => '削除するプライマリキー値',

'pms/scenario' => '/data/read',
'data/read/fields' => '更新するフィールド...',
'data/read/where/fields' => '条件フィールド1;...',
'data/read/where/fields/条件フィールド1/value' => '条件フィールド1の値',
'data/read/where/fields/条件フィールド2/type' => 'between',
'data/read/where/fields/条件フィールド2/values' => [10, 200],
'data/read/where/fields/条件フィールド3/type' => '<=',
'data/read/where/fields/条件フィールド3/value' => 条件フィールド3の比較値,

ダミーデータ生成

ダミーデータなんか生成する機能もあればいい。

'customer_data/@definition/brief' => '顧客',
'customer_data/type' => 'database',
'customer_data/table' => 'product',
'customer_data/fields' => 'address;user;tel',
'customer_data/fields/address/dataType' => 'address',
'customer_data/fields/user/dataType' => 'personName',
'customer_data/fields/tel/dataType' => 'phoneNumber',

'pms/scenario' => '/data/dummy',
'data/setup/dataset' => 'customer_data',
'data/setup/count' => 100000,

これでそれらしくて個人情報にも抵触しない住所や氏名や電話番号の顧客データが10万件生成されるみたいな。

水平分業できる仕組み

ちなみにDB定義の部分もインデペンデントなので、DBスペシャリストが携わればいい。

まずはスタブを定義しておく。

'product_data/@definition/brief' => 'プロダクト',
// 'product_data/type' => 'database',
'product_data/data' => [
  ['owner'=> 1, 'project'=> 1, 'caption'=>'プロダクトA', ...]
  ...
],

これをフロントエンドやAPIで使う分だけ用意すれば、システムのほかの部分は動く。
後はDB担当者がじっくりと定義すればいい。
リアルテーブルにしようがビューにしようが、フロントエンドは知ったこっちゃない。

ESPフレームワーク

と、これがESPというフレームワークのポリシー。
いうなればドラえもんのポケットかな。
あったらいいなを盛り込んである。