DB分からないー、とか言っていたら貸してもらっていました。
借りたのは良いけれど積んでいたので、この機会に若干飛ばしながらも読み切る。
おおざっぱな感想としては
- 業務向けっぽい
- データベースってデータ管理フレームワークなのだな
- どっちかというと読み物
どうして業務向けかというと、データベースについての話はするのだれど、業務にとって重要かそうでないかとか、自身の経験に基づいているっぽい意見とかが多かったのでそう感じた。おそらく苦労があったのだろうな、とか。
データベースってデータ管理フレームワークなのだな、というのは当然っちゃ当然の話。だけれど、多数の言語から統一インターフェース(SQL)でアクセスできるもので、中身は高速化だのトランザクションだのって実装されている、という点からなんかフレームワークっぽいなー、とか。それを言えばファイルという存在自体フレームワークか、とか書いてて思わなくも無い。
どっちかと言うと読み物、というのは歴史とか経験とかそういった部分も解説されているから。あと、正規化手法とかそういったものは省略されていて、現場ではどうするか、という部分に重きを置いている感じがあったので。あと、2005年な本だったりするので、若干気になるところもあるけれど読み物チックなので良いかな、とか。
とゆーことで読んでて思ったことの列挙とか。若干眠いお時間なので列挙するだけで。
第1部 : DB設計総論
- いろいろ変更とかありえるデータを想定したい、というのが念頭にあるみたい。
- 単価が顧客によって変わるとか
- 内部外部で呼び方が違うとか
- そういう意味では負の遺産っぽいな、とか
- 仕様変更や想定外の要素などが過去にあって大変だったのだろうな、とか
- そういう意味では経験を語っている本っぽい
- 解決手法として、リソースには unique id を振って、属性とか関連とかを柔軟に追加できるようにしようよ、って感じだったよーな
- あとツッコミとして、コードって何やねん、ってなった
- なんかこう、顧客コードとかっていう物体。idとは別らしい。
- code も identifier っぽくてユニークじゃないのか、ってツッコミたかった。
- unique でない「コード」というもの存在している、ってことなのかもしれない
- そもそもDBとはレポート生成システムであるとのこと
- DBってデータマネージメントフレームワークぽいな、とか
- データに関する処理を一元実装してしまったもの
- 利用するための共通インターフェースがSQL
- ストアドプロシージャ便利そう
- プログラミング言語側でSQL組み立てがいらないので、処理もRDBMSに投げられる
- でも使われているのか、とかって思案が。面倒そうだし。
- ActiveRecord とか内部でSQL組みたててそうだよなー
- RDBMSの特性を理解しようね、とか言ってるような
- ハードウェアスペックに依存した部分もあるよ、とか
- 正規化の遅さ速さとかって話以前にね
- sql は batch であるとか
- 何をするにもデータを読むためにselectしちゃうよね、とか
- これを知らないでやるととんでも無い処理を書いちゃって遅くなるよ、とか
- ハードウェアスペックに依存した部分もあるよ、とか
- イベント/リソース でのデータベース設計
- イベントは 「* する」のように言えるもの
- リソースは 5W1H的なもの
- みたいな視点でテーブルを作ってみよう、って感じだった
- 「One fact in one place」
- 「データは蓄積することのみに意味は無く、それを元にアウトプットするための資産である」
- 「プログラムそのものには価値は無く、どのようにデータを扱うかが重要なのである」
0 件のコメント:
コメントを投稿