伝票モデルが出来るまで

とっても長い・・・(-_-)゜zzz…

あれはまだ普通のSIをやってた頃というかSIerという言葉も殆ど無かった頃
T字形ERの本を読んで衝撃を受けた。
この方法ならそんなに難しくなくテーブル設計できるなぁと。
ポイントは帳票、伝票などの書類をキー項目とその従属に分けるっていうのが頭の中に凄く残った
キー項目と従属に分けるという考え方が正規形の考え方とも非常にマッチしてるし方法が自然なので・・・
しばらくすると全く違う方法で自分の中で出来るようになってたｗ
って言っても基本はグループ化だけなので、難しくはなかった

それからしばらく実際のDB設計をいくつも見たりして気がついた事
DB構造の中には

キー項目
キーに従属してる項目
管理用と称してる項目
関連に使う項目
状態に使う項目

これらが存在してるなと。
＃ちなみに、現時点では他にも発見してます。

それから時は流れてSeasarが出た頃
S2Daoのα版をみてこの流れでデータアクセスが簡単になって、画面周りの実装も簡単になれば・・・
残りは・・・状態だけか！って事でJavaの素人が作り始めたBuriシリーズ。というか最終形はぶり

ぶりの最終形の実装まであと少し！ってなった頃
個人的にS2Daoが扱えるデータ構造に不満が出てきた。
S2Daoは非常に良いデータアクセスライブラリなんだけど・・・
出来ることならデータをそのままI/Oさせたいなと。
正規化する前の伝票だったりをそのままストレージに保存しても、ぶりで状態管理すれば伝票の管理は出来るんじゃないかと。
検索は全文検索すれば解決！みたいなざっくりした方針を考えた。
＃この後は紆余曲折、失敗作含めて色々と。最終的には某S社のプロダクトBが生まれた

で、結論から言うと伝票をそのままストレージに保存するのは業務システム開発では得策ではない(SQLは捨てれない)ので
RDBでなんとかする方法を考えた。
そして出来上がったのがDenpyoモデル
ということで、c11tっていうのは主にデータの関連を扱うプロダクトです。