ショボいＤＢ設計で突っ走るための５０の方法 - 設計者の発言
ＤＢ（データベース）設計の良し悪しは、開発プロジェクトのパフォーマンスに決定的な影響を与える。ところが、ショボいＤＢ設計のまま突っ走るためにその場をしのぐ方法が山ほどある。５０はある。ポール・サイモンの歌みたいだ。 私は駆け出しの頃、いろいろなプロジェクトの設計書を覗きまわるのが好きだった。「プログラム仕様書」は情報量が多すぎて手に余ったが、「テーブル定義書」からは短時間で多くのことを学べた。 読み漁るうちに、設計者の馬脚がＤＢ設計に現れることがわかってきた。ＤＢ設計はある意味で、担当者の論理構成力や言語能力の結実である。ＤＢ設計書を半時間ほど眺めれば、そのプロジェクトが「うまくゆくかどうか」まではわからないにせよ「困ったことになるかどうか」は予測できた。とくに、ＤＢ設計からシステム要件を把握しにくいプロジェクトは、規模が大きければ決まってデスマーチに突入していった。 私はコトナカレ主義の
ＸＥＡＤのＸは、ＸＭＬのＸ - 設計者の発言
ＸＭＬ(eXtensible Markup Language)が鳴り物入りで登場してから７年たつが、いまだに筆者には、ちまたで言われるようなＸＭＬの利点がもうひとつピンとこない。とくに「データがその意味とセットで保管されている」とか「データ様式の設計や変更が容易」といった「利点」がわからない。その疑問を説明した後で、ＸＥＡＤにＸＭＬが組み込まれるきっかけになった、あまり意識されない別の利点を示そうと思う。読者がＸＭＬを理解するための参考になればうれしい。 ◆データがその「意味」とセットで保管されている？ ＸＭＬの特長として最初に紹介されるのが、「データがその意味とセットになって保管されているゆえに、データの検索や交換がしやすい」という点だ。たとえば、次のようなＸＭＬデータがあったとする（ブログページ上でＸＭＬと認識されないようにカッコやスラッシュを全角にしてある）。 ＜注文＞ ＜得意先名＞
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
