スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
05/05/09:20 [PR] |
11/30/09:49 DB設計者のバイアス昨日、知り合いのSEからDB設計で初めてMySQL使うらしくデータ型について相談された。
小数点以下1桁固定のカラムは何型? と聞かれたので、(何を悩んでいるんだ?と心の中で思いながら)DECIMALとかNUMERICとかで良いんじゃない?と答えたら、 3.8+4.2=8 の8を8.0ではなく、8にしたいんだと、言われた。 さらには、文字列で持とうかな、とかブツブツ言ってた。 なんか、最近twitterで見かける、どこかの小学校の採点の話を思い出した。 (これとか、http://headlines.yahoo.co.jp/hl?a=20161129-00000081-it_nlab-sci) ちなみに、 じゃ、結局どれが正解ですか? という感じでこれだけの情報で判断しようとする人はDB設計者には向いていない。 これはケースによる。 例えば、文字列で持つのがナンセンスかというと、もう今後値の変更も計算もなく、単に表示にしか使われないのであれば、ある意味文字列で持てば最速で表現できるので悪くない。 後々、このカラムの値がSQLレベルでの計算に用いられて厳密に行きたいのであれば、やはり固定小数点型のDECIMALとかNUMERICが良いだろう。 例えば、整数部分の桁数がすごく大きくて、小数点以下なんて正直どうでも良いようなレベルの計算をするのであれば、浮動小数点型のFLOAT、DOUBLEでも良い。 他の視点として、そもそもSQLで計算するのか、例えばPHPとかで一度受け取って計算(つまり一度キャストされる可能性もある)あるいは表示するのか、でも話が違う。 これを、私は、DB設計者のバイアス、と呼ぶ。 DB設計では、DOAでデータにまず着目する、それに対して、設計者はバイアスをかけることで、現実のDB設計に落とし込む。そのバイアスをかけるためにはシステム全体の世界観を理解する必要がある。 だから、業務理解なくしてDB設計はできない。 弊社はいろんなスタイルのSEがいる。画面設計とか詳細仕様はプログラマにお任せするスタイルもあれば、その辺も細かく指示するSEもいる。 ただ、DB設計だけは、お客さんと直接話すSEが担当するというポリシーを採用している。会社としての理由はもしかすると別にあるかもしれないが、少なくとも私がそのポリシーに賛成する理由は、より良いシステム構築には上記のDB設計者のバイアスが必須だと考えるからである。
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
|
06/20/19:14 思考のスピードで何かを表現することはできないふと思った。 思考のスピードで何かを表現することはできない。 例えば、画面設計。 画面設計も手書きであれば、1画面2分もあればできる。 問題は、それで出来上がった設計はあくまで設計者の頭の中だけであって、 それを伝えるには何倍もの時間が必要ということ。 そもそも私の場合、手書きの文字は読めない・・という問題が・・・ある。 昔から、数学の宿題で指された時は、 ノートのぐにゃぐにゃした文字を眺めるフリをしながらその場で考えて黒板に書いてた。 ただ、仮に、私の字がとても綺麗だったとしても、 考える作業と、伝えるための作業は別にするのが良いと思う。 そもそも作業の目的が違う、目的が違えば使うツールや手段も違う。 集中して考えるときは、フリーハンドで象形文字みたいなものをぐにゃぐにゃ描くのが良い。 学生時代はA3の画用紙ノートが大好きだった、それを豪快に使ってどんどんページを切り替えながら書いていく。 で、ある程度(30分くらい)集中して考えたら、あとは頭の片隅にその問題を追いやって、良い考えがふとした瞬間に湧いて出るのを待つ。アイデアを出す時には、工数よりも期間を重視する。つまり、同じ3時間でも、集中して3時間考えるより、1日1時間を1日おきに3日やった方が良いアイデアがでる。 逆に、手を動かす作業は、一気に集中して作業する。その方が、ワーキングメモリーを有効活用できて効率が良い。 大人になって思うことは、きっと、仕事は、考える作業は1割くらいで、仕事の9割くらいは伝えるための作業なんじゃないかということ。 そして、伝えること、表現すること、って結構難しい。 今日は(も?)オチのない話。
|
03/28/12:23 ユニバーサルデザインと業務システムユニバーサルデザインという言葉を聞いたことがある人は多いだろう。 私の中でのユニバーサルデザインのイメージは、どちらかというと、 建物や施設などが身体障がい者の方にとって使いやすかったり、 公的なWebサイトなどで、視覚や聴覚に障がいを持つ方にとってわかりやすかったり、 というイメージが強い。 ただ、一般的な定義で言えば範囲はもっと広い。 Wikipediaでは 「ユニバーサルデザイン（Universal Design、UD）とは、文化・言語・国籍の違い、老若男女といった差異、障害・能力の如何を問わずに利用することができる施設・製品・情報の設計（デザイン）をいう。」 などと定義されている。 また、これに関連して有名な7原則というのがある。 こちらもWikipediaからの抜粋になるが ユニバーサルデザインの7原則 The Center for Universal Design, NC State University による。 1. どんな人でも公平に使えること。（公平な利用） Equitable use 2. 使う上での柔軟性があること。（利用における柔軟性） Flexibility in use 3. 使い方が簡単で自明であること。（単純で直感的な利用） Simple and intuitive 4. 必要な情報がすぐに分かること。（認知できる情報） Perceptible information 5. うっかりミスを許容できること。（失敗に対する寛大さ） Tolerance for error 6. 身体への過度な負担を必要としないこと。（少ない身体的な努力） Low physical effort 7. アクセスや利用のための十分な大きさと空間が確保されていること（接近や利用のためのサイズと空間） Size and space for approach and use というものだ。 まさに、誰にとっても利用することができる、という感じだ。 我々も、ECサイトや不動産や求人情報などの紹介サイトなどは、多種多様なユーザーを想定する必要があるので、そんなシーンにおいてはこの7原則は有効だろう。 ただ、業務システムはどうだろうか? ここではより狭義の業務システム、すなわち、業界や業務形態、業務フローなどが特殊であるが故に、一般のパッケージやASPでは非効率が発生するため、ゼロからフルスクラッチで作成するようなシステムを想定する。 このようなケースにおいては、ベストなシステムはかなり尖ったものになり得る。さらに言うと、そのシステムのユーザーでも、そのシステムに接している時間の長短、権限の有無、重要性の高低などには違いがあり、どのユーザーにとってベストなシステムかと細分化してみる必要がある。 実は世の中で実際に稼働している業務システムは、このようにより狭い範囲の人間のために最適化されていることが多い。外から見ると、一見して、イケていないなとか酷いシステムだなと思うものでも、それが出来上がった背景には歴史や思い入れがある。それはおそらくそのプロジェクトを担当したSEやクライアントの担当者しか完全には理解できないものであろう。 ということで、世の中にこんなにもたくさんの便利なクラウドサービスやフリーソフトが出回っても、オリジナルの業務システムをスクラッチで構築したいという要望が消えることがないのは、上で書いたように、誰にとっても良いものではなく、ある特定の人間にとって最高(もしかする大勢の人にとっては最悪)なシステムを作りたいという要望がなくなることはないからである。 築地市場の競りのやり方をもっと誰にでもわかりやすい仕組みにする必要もないし、何かのコレクションをたくさんディスプレイしているマニアな人の部屋をホテルのような部屋に変える必要もない。 フルスクラッチの業務システムは、大量生産とは異なる工程や手法で作成するので確かに手間がかかり価格も高くなる。 でも、私たちの作る業務システムの贅沢さは、特別に作っている工程にあるのではない。特別に作られたものを使い続け、毎日その利便性などを享受できる、その日常こそが「贅沢」なのである。 つまり、フルスクラッチで作ったから価値があるのではない。 背景に、まるで、二日酔いの朝にその人の健康を気遣って出されるお茶漬けのような優しさが溢れているからこそ、私たちの作るフルスクラッチの業務システムは価値があるのだと思っている。 皆のアイドルのような誰からも好かれるシステムではなく、あなたのことを理解して常に寄り添ってくれる伴侶となるような業務システムに出会いたくなったら、いつでもお声がけいただければ幸いである。
|
11/28/18:09 非正規化と未正規化は違うDB設計の世界には「正規化」という言葉がある。
より正確にはRDB(=リレーショナル・データベース)の世界に存在する言葉だ。 そして経験の豊かなDB設計者は時々こんな言葉を口にする。 「パフォーマンスを重視して、その項目は"非正規化"しておいた。」 そんな言葉に新人DB設計者はなんとなくカッコ良さを感じる。 「正規化？ 知ってるよ。でも、ここは あ・え・て 正規化したのを崩したの!!」 というロックな感じである。 そうまるで私が 「あー、 私はKY(=空気読めない)ではなく、 AKY(=あえて空気読まない)なので・・」 と答える時のような・・・(蛇足) この「あえて」というのはとても大事だ。 ”非正規化”は、必ず”正規化”の後に発生する作業である。 未だ正規化していないもの、すなわち、”未正規化”と呼ぶものとは似て非なるものなのだ。 頭の中でも良い、必ず1回はきっちり正規化し、それをあえて崩す。 私は非正規化したときには、必ずDB定義書の備考欄に「非正規化」とコメントをいれる。 PGは非常にロジカルな思考をする生き物である。 だから、パフォーマンス等の諸事情から非正規化された状態は一瞬理解に苦しむ・・・はず。 ということで、今日はそんな KY(=空気読めない) と AKY(=あえて空気読まない) は違う・・・ というお話でした。。あれ？
|