主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
家計における「資本勘定」とは（後編） - 設計者の発言
前回、簿記が次の「４象限」にもとづく残高構成の変化を捉える体系だと説明した。これらがさまざまな仕訳科目の最上位分類となる。 借方 貸方 ＢＳ 資産 資本・負債 ＰＬ 費用 収益 家計であってもこの分類は基本的に同じだが、「資本」がわかりにくい。家計は資本金がいくらなどといった経済主体ではないからだ。そこで資本を、決算時に資産から負債を差し引いて決まる勘定、すなわち「自己資産」とみなす。さらに費用と収益をそれぞれ「支出」と「収入」と表記してみると、「家計簿」っぽく見えてわかりやすい。 ＜借方＞ ＜貸方＞ ＢＳ 資産 負債 現預金 自己資産 １００万円 １００万円 ＰＬ 支出 収入 ――――――――――――――――――― 合計 １００万円 合計 １００万円 家計は元入れ（もといれ。元手の資金を資本金として事業を始めること）から始ま
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
