データベースを勉強する機会があると、必ずデータの正規化について学びます。 正規化とはデータの冗長性を排除したりデータのメンテナンス性を高める設計手法で、かつては高価だった記憶装置の使用コストを削減する目的もありました。またインデックスの効果が得られやすいので、統計やリレーションに使用する項目を正規化（コード化）しておくことでアプリケーションのパフォーマンスを上げることもできます。

 しかしこれを"教科書通り"に行うと開発の生産性を低下させたり、まったく費用対効果が得られないケースが多くあります。

例えばアンケート（性別、都道府県、職業、氏名、媒体、好きなペット、個人情報承諾）を収集するようなデータベースを正規化手法を用いて構築した場合、実データは以下のようになります。
--------------------------------------------------
0,12,3,"フジモト マコト","2|3|7",2,0
1,33,6,"スズキ ユカリ","5|7",1,1
0,35,8,"アマカス ジロウ","1|2|3|5",4,0
--------------------------------------------------
このデータを見ただけではそれぞれの数値の意味が分からないので"人間にとっては"可読性がよくありません。

この例を正規化しない状態（つまり非正規化）にすると以下のようになります。
------------------------------------------------------------------------------
男性,千葉県,自営業,"フジモト マコト","テレビ|ラジオ|インターネット",ネコ,承諾する
女性,岡山県,公務員,"スズキ ユカリ","中刷り広告|インターネット",犬,承諾しない
男性,山口県,パート・アルバイト,"アマカス ジロウ","雑誌|テレビ|ラジオ|中刷り広告",鳥,承諾する
------------------------------------------------------------------------------
と、このようにひと目でそれぞれの項目の意味が分かるので、一次データとしてはこのまま使用できそうです。ちなみに最近のコンピュータは性能が極めて高いので、統計などで数十万件程度のデータから文字列検索を行う場合でも数秒程度しか時間はかかりません。

Webキャンペーン応募などは期間中にアンケートデータを収集するだけの処理(INSERT)が大半なので、検索や更新は運営側の処理が多く、相対的な正規化メリットはとても低くなります。統計やレポートは通常非同期に行われる作業ですから、なんでしたらお手元の素晴らしいバックオフィスソフトで十分処理が可能です。

その昔、途中から関わることになった案件で、性別や都道府県までもがマスタテーブル化、つまり正規化されているシステムを見て驚いたことがありました（当然管理画面もあります）。設計者は何故か性別や都道府県に新たな区分が加わったり変更がありうることを想定していたようです。世の経験値が浅いかコスト意識の低いエンジニアの中には、"正規化すべし"ということを教科書通り真に受けて、費用対効果の低い正規化とテーブル増加を安易に行ってしまう方がいるようです。

以前述べたとおり、データベース（テーブル）数とコスト・工数には強い相関性がありますから、「そんなに細分化したテーブル設計にお金を支払ってくれるなんてずいぶん太っ腹なお客様がいたもんだなぁ」と関心すらしてしまいます。逆にお金と時間を余分に頂かずにこのような設計を行った場合こそプロジェクトが"デスマーチ"となる大きな要因になるでしょう。

正規化とはコストと付加価値を十分見極めて設計する必要があり、つまり"ビジネス要件"でもあるのです。

データベースすなわちテーブルを設計する際、要求仕様にかかわらず、いかなる用途であっても必ず記録した方がよいメタ情報があります。これらの情報記録はWeb系システムの開発を行う組織であれば"データベース設計指針"として社内標準の一つとしてもよいのではないでしょうか。 

1. 登録日時
   「日時が無い情報は情報ですらない」と言ってもいいくらい必須の情報です。
   
2. 更新日時
   データに変化のあった日時を記録することは不具合の検証にも役立ちます。
   
3. リモートIPアドレス
   アクセス元を記録することで万一不正アクセスがあった場合の調査やセキュリティ対策に用いることができます。またプロバイダや地域、企業、組織を調べてマーケティングに利用することもできます。
   
4. ユーザエージェント
   ユーザが使用しているブラウザ（バージョン）、OS、モバイル・スマホ機器などを分析することで、サイトの品質向上やマーケティングに利用することもできます。
   

その他に、サーバが複数台となるシステム構成では"サーバ自体のIPアドレス"も記録することをおススメします。どのサーバを経路したかがわかるので、不具合調査（どこのログを見たら良いか）や負荷分散の確認に役立てることができます。またレコードの論理削除を行ったことがわかるように、"削除日時"を設けるケースもあります。

情報システムやWebサイトにてデータベース（ここではDBMS）を使用する意義は様々ありますが、主な役割は"必要な情報を整理された形で高速に取り出す機能"になります。

ひとえにデータベースが単なるファイルと異なる点は"インデックス"が使用できるところにあります。

インデックスはその名の通り、ドキュメントの見出しや目次のことですが情報量が増えれば増えるほどその効果が高まります。

例えば以下のような不規則なデータの集合があったとします。
poiuytrgewqlkjhgfdsamnbvcxzaqwertyuioplkjhgfdsmnbvcxzasdfghjklqwertyuiop
この中から"g"という文字の出現回数を数えるには先頭から一文字一文字注意深く観察する必要があります。

この情報が以下のようにアルファベット順に整列していた場合はどうでしょうか、aaabbccdddeeefffgggghhhiiijjjkkklllmmnnooopppqqqrrrssstttuuuvvwwwxxyyyzz
あっと言う間にgが4個あることがわかりますよね。

このようにあらかじめデータの整列を(実際には論理的に)行い、検索時にデータを瞬時に取り出せるような仕組みがインデックスの主な役割です。なお、利用者が数百万人、数億人いるようなSNSサイトであっても瞬時に自分のプロフィールを呼び出して認証を行ったり、変更を行えるのもインデックスが有効に機能しているからです。

しかし、これだけデータベース活用に重要であるにも関わらず、システム開発において中心となるプログラマの中にはデータベースのインデックスについて関心（あるいは興味）やスキルが不足している人が比較的多いという残念な現状があります。開発時や運用初期段階ではデータ件数も少なく、また無理な工期も少なくなくデータベース性能にまで気が回りにくい状況もあるのでしょう。

データベースを運用して数年も経ってから、「最近どうもデータベースのレスポンスが遅い」という現象が発生し、詳細に調査を行ってみたら必要なインデックスが設定されていなかった、なんてことにもたびたび遭遇します。この時きちんとした技術者であれば原因の一つとしてインデックスの不備が思い浮かびますが、安易に「サーバ性能が足りないから」と判断してメモリやCPUの増強を提案される場合も多いです。

私の経験的にはデータベーストラブルの7割以上がインデックスの不備によるものです。

私はインデックスに不備がある状態をお客様に説明する際には「でたらめに本が並べられた本屋で必要な本を探し求めることを想像してみてください」と伝えます。欲しい本が比較的簡単に見つかったり"無いこと"がわかるのは書店の店員がキチンと分類を行い、部分的にあいうえお順に並べてくれるからです。たまに、特に気にしていないと思われる本屋があったりしますが、我慢できるのは商店街にあるような小さな商店までですよね。