 |
|
|
|
|
|
| 1 2 3 4 次のページ
|
|
| データベースのテーブル設計
|
第1回はツールを使った実践的なデータモデリング手法、第2回はその基礎となるERの知識とツールの活用方法について解説しました。よくあるデータモデリングそのものの解説はこれくらいにして、今回からはデータベースのテーブル設計をテーマにします。データベース設計を行う際にみなさんが迷うようなことを1つずつ取り上げ、一緒に考察して行きたいと思います。
|
| 解が1つとは限らないデータベース設計
|
2進法の世界に生息しているせいか、我々エンジニアは物事を正解か不正解かに断定してしまいがちです。また、非攻撃的な生き物なので表立ってはっきり主張する機会は少ないのですが、「絶対こうじゃなければだめだ」「こんなのは信じられない」などと結構固い信念を持っている人が多いようです。
確かに数値計算の世界では、1 + 1 = 2というように正解が求められます。しかし、ふと世の中を見回してみると、実社会はむしろ正解が1つとは限らないことに気づきます。データベースの設計も同じです。
もちろん「すっきりとした設計」というものはありますが、ケースバイケースで様々なやり方があります。例えケースが同じだとしても、どれが正解と一概にいえない場合が多いのです。物事には一長一短があるので、設計者の考え方によって様々なやり方があると心得てください。
|
| テーブル名、カラム名をダブルバイトにするか
|
「みなさんはテーブル設計する際に、テーブル名やカラム名に日本語を使いますか？」著者はセミナーなどの際に、一種のタブー視されているこの質問を投げかけてみます。一般に「使わない」というシングルバイト派の方が多いのですが、携わっているRDBMSによっても割合が違うようです。
先日、オラクル関連とマイクロソフト関連の両方のカンファレンスで講演する機会があったのですが、Oracle技術者主体だと9対1で日本語を利用しない方が圧倒的に多かったのですが、SQL Server技術者主体だと5対5といった結果でした。
データベースの書籍や雑誌などで、著名な方々が「テーブル名やカラム名にダブルバイトは使わないように」と書いています。ですから、こういう会場でダブルバイト派であると認めて手をあげるのは、ちょっと勇気のいる行為だと思います。
著者自身は、どちらでもかまわないと考えています。むしろ、社内でも少数派のダブルバイト派だといえます。もちろん、プロフェッショナルですからユーザや市場にあせてテーブル名やカラム名にシングルバイトを利用する機会の方が多いのですが、何のしがらみもなければ迷うことなく日本語を使用します。
カラム名に日本語を使用するメリットは、一目で理解できるというわかりやすさです。表意文字である漢字を使えるので、名称を短くすることができます。例えば、「customer_currency_code」というようなカラム名も、「顧客通貨コード」とすれば一目瞭然です。わかりやすさは生産性の向上に直結しますし、他の人が見ても簡単に理解できることでメンテナンス性も向上します。
一方、デメリットは新しい技術・製品対応時に不安が残るということでしょうか。「現在は問題がなくても、この先に日本語対応に問題が生ずる可能性がないとは断言できない」というのがシングルバイト論者の主張するところです。
確かに著者も過去様々な障害に直面してきました。しかし、その経験を踏まえても、ベンダーの意識向上もあって最近はリスクよりメリットの方が多いと考えています。別にここでダブルバイトを勧めているわけではありませんし、不毛な論争をしたいとも思いません。しかし、「テーブル名やカラム名にダブルバイトを利用することは絶対駄目というものではない」ということをお伝えしておこうと思います。
|
1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。
常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。
国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。
|
|
この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。
ご意見、ご要望にお応えします！ インプレスIT INSIDE
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
