これを読んでる人に問題です！
質問
特に、システム屋さんに質問です。
辞書のデータ構造を考えてください
え〜！？といきなり思うかもしれないね。が、とにかく考えてみてください。なぜ、「辞書のデータ構造を？」という問いには、「今、俺が作ってるからだ！より良くしたい」という思いからだ。一般的にデータ構造を考える必要性については、「ここ」を参照してくれ〜
辞書といえば、見出し語−訳語の対が基本的な感じだよね。なので、表形式で見出し−訳語対がずらずらと並んでいく。そんな感じが直感的には浮かぶと思う。が、ここではサーバー上でのデータ形式です。データベースに放り込むデータの形式。どんな形式にしますか？
「辞書のデータ構造と言えばこれが最高だ」というような可能な限りそして疑いの余地もないほど完全なデータ構造を考えてみてください。
要求がなければ考えられないよ。という人は辞書という「業務領域」に対して理解を深めて、想像しうる最大限の要求を考えてみてください。そして、普遍性が非常に高いデータ構造を考えてみてください。
僕も考えてるので、考えをいづれ発表してみるつもりだよ。そして、批判をいっぱいしてもらいたい。日本人は批判するの好きだしね（笑）。
僕の考えの根底
僕の考えの根底には、DOAがあります。この考えはプログラム（フロー）よりもデータの方が普遍的だというものです。そして、佐藤正美氏（SDI）の影響をモロに受けてます（笑）。彼は、以下のように言ってます。
- データ構造を 100％正規化して、事業の「強みと弱み」を解析する やりかたを ご存じですか。
- データ構造を 100％正規化して、プログラムのソース・コードを削減する やりかたを ご存じですか。
- データ構造を 100％正規化して、「驚異的な」高パフォーマンスを実現する やりかたを ご存じですか。
実は彼の講義を受けて、データ構造という事業の証左を得ながら事業の構造を解析することは可能だと思う*1。その結果として、SWOTの分析もできるでしょうという思いですね*2。
他の2点については、彼の言うような「データ構造を100%正規化」することを見よう見まねでやってみて（だからまだまだ分析力は甘いけれどね）、プログラムも実際に書いてみて、コードの削減、高パフォーマンスは達成できると思った。
また、別の視点からいっつも仕事で同じようなデータ構造の分析を行うことにも気づいていた。組織のデータ構造、履歴データの持ち方などなど。同じことを繰り返すのも馬鹿らしい。そこで、可能な限り最高のデータ構造を作ってしまって、それをお客さんごとにカスタマイズしてしまえばいいような気がしてる。う〜ん、自分の思いを全て言えてないな〜。。。
ただ、まだまだ勉強中です。アナリシスパターンやビジネスモデリング関連の本を読んで勉強してます。が、読めば読むほど、同じようなパターンがいっぱい出てくる。なのに、使い勝手が良いようにまとめられたりもしていないし、「データ構造」をオープンソースにもしてない。すれば、大分開発が楽になるのにね。ただ、公開してしまうとどうやって飯を食うかも問題だ（笑）
補足2
システム屋さんではない人に簡単に説明。現在サーバー上で頻繁に使われているデータベースはリレーショナルデータベースというものです。これはごくごく簡単に言ってしまえばデータを複数の表形式にして格納しておくものです（直感的にはね）。そして、各表のキーを元に、複数の表に関連を持たせることができます。で、僕の要求でサーバー上でというのは、どんな表をいくつ作りますかという意味です。
見出し語−訳語対を一行として、複数行にわたってデータを書いていく。これが、普通の人がやるデータの記憶方式です。パソコンでこのデータ形式を用いるのはまぁいいかもしれません。パソコンのCPUは個人に割り当てられていて、あなたはそれをフルに使い切ることができるから。
でもね。サーバーだと話が違います。1万人がアクセスするとしても、パソコンのCPUの10000倍も性能が良いわけではないです。メモリーも1万倍もあるわけではありません。こんなリソースが限られている状況で、システム屋さん(SE)はシステムを作らなければなりません。
そこで登場するのが、データベース。複数の表形式でデータを格納し、キーで結びつけておく。こうすると格段にデータの検索・更新が早いんです。だって、数学的にエレガントにまとめられた理論とそれを応用した専用のソフト(リレーショナルデータベース)を使っているのだから。
ただし、うまくやらないと、性能は出ないし、データの再利用もできない。下手に作ると辞書で言えば、対応する言語を増やすだけなのにデータ構造は変えなきゃならんし、それに伴いプログラムも再度書き直しなんてことになる。それが嫌だから
