テーブル設計は実装の後に！：ベンチャー社長で技術者で：エンジニアライフ

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル

[t_yano]

テーブル設計を画面確定後にするのは一般的な手法なんだと思ってた...。だってなにを表示したいのか、なにを管理したいのかわからないでテーブル定義なんてきめられないでしょう？？

[kilrey]

モジュール化すら守られていないという(ありがちな)現場の実例。

[takkada]

結局セミナーの告知だった。

[houyhnhm]

これ、多分大手ベンダーでは一般的な作り方なんだが。ただ、これやるとシステムのメインテーマがずれたくる。パッケージ適用パターンでは大体死ぬ。

[masa8aurum]

・ダミーのデータを返すストアドプロシージャを用意し、UIも含めた「動くもの」を作って顧客に見せる。テーブル設計（の確定）は後回しにする

[uxoru]

SQLを生成する作業を「実装」と見るか「設計」と見るか？今まで「実装」だと思ってたんだけど、「設計」とした方がしっくりくる。

[puriketu99]

コメ欄あとでよむ

[kiyo1978]

Annotated link http://www.diigo.com/bookmark/http%3A%2F%2Fel.jibun.atmarkit.co.jp%2Fg1sys%2F2009%2F01%2Fpost-037e.html

[sixpetals]

一瞬、「え」と思ったが、普通に納得できた。 // ただし、メンテを自分たちでやる前提だよね。安い他社でやるから、となるとストプロは選べない（その業界状況をブログ主は問題視してるのも分かるけど）

[takuno]

素直に考えれば、基本設計・詳細設計・実装ではなく、外部設計（実装）・内部設計（実装）とした方が効率的なはずです。

[kno]

”テーブルを利用せずに、ダミーのデータを返すストアドプロシージャ”

[d4-1977]

テーブル設計の話。RoRとか、cakeとか使うとどうだろう？

[atsushifx]

DBのモデリングもアジャイルということだと理解した。というかDB設計もRADしたいよね

[Nagise]

一口で言うと、プロトタイピングしようということ？

[yukung]

テーブル設計から業界の在り方まで．でも気持ちは凄くよく分かる．／ウォーターフォールってお役所的に仕事を進めるのが大好きな日本人（いや、大企業か）にマッチしすぎてるのかなーと最近つくづく感じる．

[ototoi]

インターフェース　優先主義は悪くないと思う・・・ただしインターフェースと実装を疎結合にできるのなら。だ。

[kahki]

ストアドのスタブ作成で、テーブル設計をアジャイルに行う

[iox]

なるほど。これもひとつの手段。SQLをちゃんと勉強したい。

[monjudoh]

なんとなくこのフレーズに納得『アジャイルでうまくいくのは、～内部が単純で、外部の要求が厳しい場合だと思う。ウォーターフォール～内部は複雑だけれど、最終の出力やユーザーインターフェイスが単純な場合』

[m-ohshita]

11

[Marin_MTB]

こういう開発がいるから運用が苦労するんだな。柔軟性は確かに上がるけど、管理する側からすればたまったもんじゃない。ベンチャーはともかく、大手じゃあり得ない。