妥当性検査をＤＢ側に集約する - 設計者の発言
テーブルフィールドの妥当性検査をどこに配置するかは、ＤＢシステムの開発において重要な問題である。大別してプログラム側に置く流儀とＤＢ側に置く流儀とがあるが、基本的に後者が正しい。 なぜなら、どのプログラムで実行されるかに関わらず同じ検査がなされるとしたら、その仕様はフィールド固有の属性とみなされるからだ。たとえそのフィールドに対する妥当性検査を実行するプログラムが１個しかないとしても、そのように考えるべきである。フィールド固有の属性については、テーブル側の定義情報を読めばひととおりわかるようでなければいけない。以前にも書いたように「カエサルのものはカエサルへ、ＤＢのものはＤＢへ」の原則で、フィールドの扱われ方に関する仕様はテーブル上に集約したほうがよい。 では次のような妥当性検査があったらどうだろう。「テーブルＡ上の関連レコードのフィールドＢの値がナントカの場合、テーブルＣ上のフィールドＤ
「動的参照関係」を手なづける - 設計者の発言
テーブル関連の「参照関係」には「静的」なものと「動的」なものとがある。後者はどういうわけかデータモデリングの参考書の中でほとんど取り挙げられないが、一定以上複雑なデータベースシステムであればふつうに現れる。開発者にとっては避けて通れないデータ構造だ。 「動的参照関係」が何かを見る前に、通常の参照関係である「静的参照関係」を確認しておこう。たとえば次のようなデータモデルがあるとする。 このモデルは「テーブルＣ上に置かれたaをキーとしてテーブルＡにアクセスし、Ａ上の項目であるbの値を手に入れる」という操作手順を含意する。この関係はまた「Ｃのaは、テーブルＡ上で規定されている値をとらねばならない」、および「そのレコードを参照するＣ上のレコードが１件でも存在しているのであれば、[Ａ]のレコードの削除は許されない」という制約をともなう（それぞれを更新制約、削除制約と呼んでおく）。以上は「静的参照関係
少人数開発と「能力プール」 - 設計者の発言
■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト（情報コスト）が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが２人のときに情報コストが１だとすれば、（１人のときなら０）、人数に従って次のようにコストは増えてゆく。 ２人 １ ３人 ３ ４人 ６ ５人 １０ ： ： ｎ人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上
プログラマではなくテスターとして現場デビューする - 設計者の発言
筆者はプログラミングは好きだったが、テストについてはずっと苦手意識があった。プログラムがそれなりに完成してしまうとそれで満足してしまって、さっそく次のプログラムにとりかかりたくなる。結局、システムテストの段階でハデにバグが見つかってどれだけ周りに迷惑をかけたかわからない（今思い出しても冷や汗が出る）。「自分に代わってテストだけをやってくれる要員」がいてくれたらと本気で願っていた。 だから、１年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。その発想は考えれば考えるほど合理的かつ発展的だ。筆者なりに肉付けした形で紹介したい。 ◆新人は現場のお荷物である 多くのソフト開発企業での新人教育が何から始まるかというと、大学の一般教養課程のような「コンピュータ概論」だったりする。その後に「ソフトウエア分析・設計」とか「プログラミング」の学
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
