スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/02:30 [PR] |
11/11/18:27 DBはまず学び、それから考えよ。==================== 【はじめに】 今日はこれから上から目線で偉そうなことを書きます。 最近、社外のPG仲間がダメなDB設計のせいで苦しんでいるのを見て、いつか言いたいなと思いつつ言わなかったことを書きます。 ==================== あなたの専門は何ですか? と聞かれたら、たぶん、私はデータベースです、と答えます。 社会人1年目の春、研究所時代に ・国家試験のデータベーススペシャリスト ・オラクルマスター ・SQL ServerのDB設計分野でのマイクロソフト認定プロフェショナル 等の資格をとり、 その後もデータベースを自分の専門分野として研究に勤しみました。 実戦も、アドバイザリー業務を含めれば、関与したDBは数百件。 理論面、実践面、共に一応専門家を名乗っても良いのではないかと無謀にも自負しています。 そんな私だからDBに関する技術談義が好きでいつもやっているかのような印象を持たれるかもしれないですが、理論的なバックボーンない方々とは、基本的にDBに関する議論はしません。 これは非常に驕り高ぶったように思われるかと思いますが、そのような方々と行うDBに関する議論は、単なる宗教論争になるからです。 実戦の中から経験則で帰納的に良い設計理論を構築しようというのは無謀だと思います。それでは圧倒的に参考事例の数が足りません。それなりのものが出来上がる頃には引退する年になっているのではないかと思います。 それよりも、世の中の数多くの専門家が研究に研究を重ねた結果導かれた理論を学ぶ方がはるかに効率が良いと思います。また、RDBのコアな理論は数学的に導かれるものなので、ブレはありません。 その上で、実戦では、ポリシーによって、どの理論をどこまで適用するか、ということを考えます。このレベルであれば、DBに関する議論も意味を持つと思います。 例えば、非常に初歩的ですが第一正規化というのがあります。 みなさん、正規化、非正規化という言葉、正規化には第何正規化というのがある、というくらいは知っているかと思います。ただ、その実際の中身、目的、制約事項などを理解していないと、”考える”ということはできません。 第一正規化であれば、繰り返しを排除するわけですが、時として状況によっては、非正規化(正規化崩し)をすることもありえます。 例えば、全く更新がない大量のログのようなテーブルで繰り返しの回数も確実に固定されていて、参照する際に経験豊かではないオペレータがDBを直接覗きに行くことが10年に1回くらいあるようなテーブルなどはこのケースに該当すると思います。 結局、第一正規化にはその目的があり、その目的よりも重視する別の目的があればそれを採用しないのは当たり前かと思います。つまり、第一正規化の目的をはっきり理解していれば、それを辞めた時のシステムへの影響も想像することができます、それで初めて非正規化してOKかどうかというのは判断可能なのだと思います。 別の目的というのは、パフォーマンスだったり、上記のような特殊な要件での視認性だったり、その他様々な必要性から来ることが多いと思います。それらのメリットが、非正規化した時のデメリットを上回れば、それは非正規化した方が良いです。 つまり、DB設計において、”考える”とは、いくつかの取りうる設計の選択肢のメリット・デメリットを計算し比較し、その案件では何を一番重視すべきかというポリシーのバイアスをかけた上で、”選択する”ことだと思います。 理論的な枠組みのある人は、あるシチュエーションにおいて、まるでレストランで席に着いた時にメニューを見るような感じで目の前に選択肢が見え、その中でベストなものを選択することができます。 将棋のプロは定石を学び、その定石を適用すべき状況を学び、メリット・デメリットを学び、その上実戦例としての過去の棋譜を読み、そして初めて、”考える”のだと思います。 DB設計においても同様のことが言えると思います。 DB設計で悩んでいる暇があったら、まずは一通りの基礎を学ぼう、と言いたいです。今後の長いDB設計人生で言えば、それはほんの一瞬と言えるほど短い時間です。その上で、初めて”考える”という旅に出ましょう。 DBはまず学び、それから考えよ。 全ての、PGからDB設計の勉強をせずにそのままDB設計する立場となった人々に捧げます。 偉そうですみませんでしたm(_ _)m
PR
|
|
|
|