タコヤキ業務にタコヤキテーブルは必要か - 設計者の発言

前々回と前回の記事で紹介した「WEBサービス事業管理システム」のモデルと実装が、「CONCEPTWARE/サービス管理」として近日公開される（2016/10/12に公開済）。このモデリング課題にもとづいて大阪と東京でハンズオンセミナーを開催したわけだが、その中で気づいたことをひとつ紹介したい。DB構造が業務構成や機能構成に必要以上に引きずられてはいけないという話だ。 １回目のセミナーではシステム要件をほとんど口頭で説明しただけだったのだが、２回目では時間の節約のために、あらかじめリストにしたものを事前に配布したうえでデータモデリングしてもらった。その一部が以下である。 ・顧客に利用明細書を送付した時点で売上確定され、顧客は規定の銀行口座に利用料を振り込む ・利用料が未入金であるような顧客に対しては、適宜に督促メールを送信する ４～５名で８チームに分かれてモデリングしたのだが、ほとんどのチー

[fumisan]

普通のテーブルにカセットコンロにたこ焼きプレートでいいだろう、ということかなー。確かにそのとおりだし、その方がクレバー。専用にすると後のメンテナンスが大変。

[kawa-_-kawa]

画面案からDB設計していくと、DBは単純なGetter/Setterに成り下がり、業務作業から設計すると不安定なDBが出来上がる。ほんと「三要素分析法」超大事！

[airj12]

画面単位にテーブル作ろうとする人もいるしね(性能要求面で正しい場合もあるけど)

[northlight]

性能・多重度・トランザクションサイズ・移行・耐障害性（トラブル時の影響）とかはどうなるんだろう。小規模サービスならサマリテーブルでいけるのか？作り方とか非機能設計次第なんかなあ・・

[koyancya]

基本的にはこれだけ考えてれば良さそうな気がする -> "それらの業務全体が規定する「関数従属性」や「ユニーク制約」にもとづいてデータ構造をまとめている。"