数百のレコードや数百万のレコードを保持するデータベースを扱っている場合でも、適切なデータベース設計が常に重要です。情報の検索がはるかに簡単になるだけでなく、将来のデータベースの拡張も簡単になります。残念ながら、将来的には困難になる可能性のあるいくつかのトラップに入るのは簡単です。
データベースを正規化するというテーマに書かれた本が全部ありますが、ここに示されている一般的な間違いを避けるだけなら、適切なデータベース設計が正しいでしょう。
データベースの間違い＃1：テーブル内のフィールドの繰り返し
優れたデータベース設計のための基本的な経験則は、繰り返しデータを認識し、それらの繰り返し列をそれぞれのテーブルに入れることです。表のフィールドを繰り返すことは、スプレッドシートの世界から来た人には一般的ですが、スプレッドシートは設計上フラットになりがちですが、データベースはリレーショナルでなければなりません。それは2Dから3Dに向かうようなものです。
幸運なことに、繰り返しフィールドは通常簡単に見つけることができます。この表を見てみましょう：
| OrderID | プロダクト1 | 製品2 | プロダクト3 |
| 1 | テディベア | ジェリービーンズ | |
| 2 | ジェリービーンズ |
注文に4つの商品が含まれているとどうなりますか？ 3つ以上の製品をサポートするには、テーブルに別のフィールドを追加する必要があります。また、テーブルの周りにクライアントアプリケーションを構築してデータを入力する場合は、新しい製品フィールドを使用して変更する必要があります。そして、ゼリービーンズの命令をすべて順番に見つけるにはどうしたらいいですか？ SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OR Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'。このようなSQL文を使用して、テーブル内のすべての製品フィールドを照会する必要があります。
すべての情報をまとめて1つのテーブルにするのではなく、それぞれが別個の情報を保持する3つのテーブルを用意する必要があります。この例では、注文自体、すべての製品を含むProductsテーブル、および注文に製品をリンクさせるProductOrdersタブレットに関する情報を含むOrdersテーブルが必要です。
| OrderID | 顧客ID | 注文日 | 合計 |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| 製品番号 | 製品 | カウント |
| 1 | テディベア | 1 |
| 2 | ジェリービーンズ | 100 |
| ProductOrderID | 製品番号 | OrderID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
各テーブルに固有のIDフィールドがどのようにあるかに注目してください。これが主キーです。プライマリキー値を別のテーブルの外部キーとして使用してテーブルをリンクします。主キーと外部キーの詳細を読む。
データベースの間違い＃2：テーブルへのテーブルの埋め込み
これは別の一般的な間違いですが、必ずしも繰り返しフィールドと同じくらい目立つとは限りません。データベースを設計するときは、テーブル内のすべてのデータが自分自身に関連していることを確認する必要があります。それは、何が違うのかについての子供のゲームのようなものです。あなたがバナナ、イチゴ、桃、テレビセットを持っているなら、おそらくテレビセットは別の場所に属しています。
同じ行に沿って、営業担当者のテーブルがある場合、そのテーブルのすべての情報は、その営業担当者に具体的に関連する必要があります。その営業担当者に固有ではない追加情報は、データベースの他の場所に属している可能性があります。
| SalesID | 最初 | 最終 | 住所 | 電話番号 | オフィス | OfficeNumber |
| 1 | サム | エリオット | 118 Main St、Austin、TX | (215) 555-5858 | オースティンダウンタウン | (212) 421-2412 |
| 2 | アリス | スミス | 504 2nd Street、ニューヨーク、NY | (211) 122-1821 | ニューヨーク（東） | (211) 855-4541 |
| 3 | ジョー | 教区 | 428 Aker St、Austin、TX | (215) 545-5545 | オースティンダウンタウン | (212) 421-2412 |
この表はすべて個々の営業担当者に関連するように見えるかもしれませんが、実際には表内に表が組み込まれています。 OfficeとOfficeNumberが "Austin Downtown"でどのように繰り返されているかに注目してください。オフィスの電話番号が変わるとどうなりますか？変化する1つの情報について、データ全体を更新する必要があります。これは決して良いことではありません。これらのフィールドは、独自のテーブルに移動する必要があります。
| SalesID | 最初 | 最終 | 住所 | 電話番号 | OfficeID |
| 1 | サム | エリオット | 118 Main St、Austin、TX | (215) 555-5858 | 1 |
| 2 | アリス | スミス | 504 2nd Street、ニューヨーク、NY | (211) 122-1821 | 2 |
| 3 | ジョー | 教区 | 428 Aker St、Austin、TX | (215) 545-5545 | 1 |
| OfficeID | オフィス | OfficeNumber |
| 1 | オースティンダウンタウン | (212) 421-2412 |
| 2 | ニューヨーク（東） | (211) 855-4541 |
このタイプのデザインでは、営業担当者テーブルの混乱の悪夢を作り出すことなく、Officeテーブルに追加情報を追加することもできます。その情報のすべてが営業担当者のテーブルにあった場合、住所、市区町村、州および郵便番号を追跡するだけの作業を想像してください！
データベースミス＃3：2つ以上の情報を1つのフィールドに入れる
営業担当者のテーブルにオフィス情報を埋め込むことは、そのデータベースの唯一の問題ではありませんでした。住所フィールドには、住所、市区町村、州の3つの情報が含まれていました。データベースの各フィールドには、単一の情報が1つだけ含まれている必要があります。 1つのフィールドに複数の情報がある場合、情報をデータベースに照会するのが難しくなります。
たとえば、オースティンのすべての営業担当者に対してクエリを実行する場合はどうなりますか？アドレスフィールド内で検索する必要があります。これは非効率的であるだけでなく、悪い情報を返す可能性があります。結局のところ、誰かがオレゴン州ポートランドのオースティン通りに住んでいたらどうなりますか？
テーブルは次のようになります。
| SalesID | 最初 | 最終 | 住所（1 | アドレス2 | シティ | 状態 | ジップ | 電話 |
| 1 | サム | エリオット | 118 Main St | オースティン | TX | 78720 | 2155555858 | |
| 2 | アリス | スミス | 504 2nd St | ニューヨーク | NY | 10022 | 2111221821 | |
| 3 | ジョー | 教区 | 428アーカーセント | Apt 304 | オースティン | TX | 78716 | 2155455545 |
ここで注意すべきことがいくつかあります。まず、 "Address1"と "Address2"は繰り返しフィールドの間違いに該当するように見えます。
しかし、このケースでは、販売担当者に直接関連する別個のデータを参照するのではなく、それ自体のテーブルに入れなければならないデータの繰り返しグループではありません。
また、避けるべき間違いとして、電話番号の書式がどのようにテーブルから取り除かれているかに注意してください。可能であれば、フィールドの書式を保存するのは避けるべきです。電話番号の場合、人々が電話番号を書く方法は複数あります：215-555-5858または（215）555-5858。これにより、電話番号で営業担当者を検索したり、同じ市外局番の営業担当者を検索したりするのが難しくなります。
データベースの間違い＃4：正しいプライマリキーを使用していない
ほとんどの場合、プライマリキーに自動的にインクリメントする番号またはその他の生成された番号または英数字を使用することをお勧めします。プライマリキーに実際の情報を使用するのは、たとえそれが適切な識別子を生成するように聞こえても、使用しないでください。
たとえば、私たちはそれぞれ独自の社会保障番号を持っているので、従業員データベースの社会保障番号を使用することは良いアイデアのように思えるかもしれません。まれに、社会保障番号を変更することも可能ですが、主キーを変更することは決してありません。
そしてそれは、実際の情報をキー値として使用する際の問題です。それは変更することができます。
データベースミス＃5：命名規則を使用しない
これは、データベースの設計を始めたときには大したことではないかもしれませんが、データベースに対してクエリを作成して情報を取得するようになったら、命名規則を持つことでフィールド名を記憶するのに役立ちます。
名前がFirstName、LastName、First_name、last_nameとして別のテーブルに格納されていた場合、プロセスがどれほど難しいかを想像してみてください。
2つの最も一般的な命名規則は、フィールド内のすべての単語の最初の文字を大文字にするか、アンダースコアを使用して単語を区切ることです。最初の単語（firstName、lastName）を除くすべての単語の最初の文字を大文字にする開発者もいるかもしれません。
また、単一のテーブル名または複数のテーブル名を使用するかどうかを決定したい場合もあります。注文表か注文表ですか？それはCustomerテーブルかCustomersテーブルですか？ここでも、OrderテーブルとCustomersテーブルに煩わされることはありません。
選択した命名規則は、命名規則を実際に選択して固執するプロセスほど重要ではありません。
データベースの間違い＃6：不適切なインデックス作成
索引付けは、特にデータベース設計の新しいものにとっては、最も困難なことの1つです。すべての主キーと外部キーにインデックスを付ける必要があります。これらはテーブルをリンクするものなので、インデックスがなければ、データベースのパフォーマンスが非常に悪くなります。
しかし、あまりにも頻繁に欠けているものは、他の分野です。これらは「WHERE」フィールドです。 WHERE句のフィールドを使用して検索を絞り込むことが多い場合は、そのフィールドにインデックスを付けることを検討したいと考えています。ただし、テーブルを過度に索引化したくない場合は、パフォーマンスを低下させる可能性があります。
どのように決定する？これはデータベース設計の技術の一部です。テーブルに置くインデックスの数には厳しい制限はありません。主に、WHERE句で頻繁に使用されるフィールドのインデックスを作成する必要があります。データベースを適切に索引付けする方法の詳細を参照してください。
