2006-07-10 [長年日記]
_ 楽々ERDレッスンを読んでいる
最近のはぶにっきが話題になっていたので惹かれて読んでみている。ああいう切れ味鋭い語り口の人の本は、読んでいて気持ちよくなるか頭にくるかどちらかだというのは分かっているので、安心して読める。（あんまり読書そのものが得意じゃないので、どう転ぶか分からない本を読むのは好きじゃないのだ。）
まだ半分くらいしか読めていないんだけど、これはかなりすっきりする本なのは間違いない。こちらに DB の基本的な素養が全然ないので突っ込んだ話はかなりの部分が分からないんだけど、それでも「ダメな設計って言うだけなら簡単だよな」と斜に構えた読者（つまりオレだ）にきっちりカウンターをかましてくれる。気持ちいい。
「ダメな設計」って言葉はあちこちで見る。それは設計が腐っているからだよ、と。しかしどこがどう腐っているのかをちゃんと言ってくれているものはあまり見ない。これは DB に限らずプログラミングでもシステムの管理でもなんでもいいんだけど、全般的に「こうするものです」的な話の流れになっている情報というのは「ではこうした場合なぜダメなのか」をあまり掘り下げてくれない印象がある。もちろんそれを掘り下げるのは面倒だし大変なんだってのは分かるんだけど、腐ってるとだけ言われても困っちゃうのも事実なわけだ。しかしこの本はなぜダメなのかが明確になっている。そこがいい。これは、設計のことはよく分からないが目の前にダメだってことだけは分かっている DB があるから、余計に強く感じることなのかもしれないけど。
ただ、3部構成*1の半分くらい読んだところで思うのは、「これ構成後付けじゃね？」って辺り。というか先に対象読者と、それ以前のレベルの人はまずこれとこれを読めと明示しておいてほしかった。付録を見れば参考文献はいっぱい列挙されているのでこの手の本としてはとても嬉しい配慮がされているんだけど、事前に絞った情報を出してくんないと、さすがにこれ全部は買えないし読めないし。
まぁこの本自体は手頃な分量なので、とりあえず第1部と第2部は細かいこと考えずにダダッと読んじゃうのがいいかもしんない。DB のことが分かっている人ならスラスラ読めるだろうし、分からなくても無理矢理ザクザク読んでしまってとりあえずレッスンしてから戻ってきてもいいんじゃないかと思う。少なくとも何が分からないのかさえ分からないレベルでない限りはなんとか読める。あー早くレッスンに入らないと。
気に入ったフレーズを書き出してみる。（ママじゃないよ。）
- 正規化には数学的な意味だけでなく業務の視点からの正規化が大事
- アイデンティファイヤ重要
- 「コード」はユーザーインターフェイスであり、ユーザーの都合、ビジネスの都合によって変更が入るので、これをキーに使ってはいけない。
- 複雑な（例外や運用時ルールの多い）業務のデータ構造は複雑になって当然。データ構造を無理にシンプルにするとプログラムが複雑になるだけ。
- データは（業務ベースでいけば）「その企業のもの」であって、「企業内の特定の誰かのもの」ではない。
- 蓄積することではなく、何らかのレポートを生成することが重要。
- DBMS にも富豪アプローチを。あえて性能を出すためにデータ構造に手を加えるのは分かりにくくなるのでオススメしない。
2006-07-15 追記
レッスン前はとても気持ちよく読めたが、実際のレッスンに入ったらやっぱりさっぱり分からなくなった。おまけに参考書籍にはどうも考え方の参考になる系のものが結構あり、教科書系のものが少ない感じ。うーん。教科書系も当たり外れあるだろうし、その辺が知りたかったんだけど、そういう目的には使えないようだ。
あくまで個人的にだけど、この本を読む前後で何を感じたかを書いておこう。
- DBMS を使えばデータ構造とプログラムの構造を切り離すことができそうで、使いこなせたら圧倒的にプログラムの量を減らせて嬉しいだろうと思っていた予想はたぶん当たっている。
- 第n正規形だの正規化崩しだの、なんだかなぁと思っていたんだけどこの本ではそこら辺は重視しておらず、少し安心した。しかし基礎的な用語が分からないことには変わりないので、何かしら教科書用意しないとなぁ。
- しかしこの本に書かれているように徹底的に業務を洗い出すのはやはり難しいだろうなぁ。何しろ自分たちの行為に無自覚な人間が多いから。まぁでもそれは絶対に無理っていう変更の要素が思い浮かぶようになったら、たぶんそれを避けるノウハウが自分の中に貯まってくるだろう。プログラムもそんな感じだから。
- ちくしょう、教科書で勉強したらもう一回戻ってきてやるぜ。
*1 付録を除いてね
