私たちは皆間違いを犯し、他の人の間違いから学ぶことができます。この投稿では、多くの問題を引き起こし、時間と費用の両方を要する可能性のある不十分なデータベース設計を回避するための多数のオンラインリソースを見ていきます。また、今後の記事で、ヒントとベストプラクティスの場所を説明します。
データベース設計のエラーと避けるべき間違い
データベース設計者が一般的なエラーや間違いを回避するのに役立つオンラインリソースは多数あります。明らかに、この記事はそこにあるすべての記事の完全なリストではありません。代わりに、さまざまな情報源を確認してコメントし、自分に最適な情報源を見つけられるようにしています。
推奨事項
これらのリソースの中で読む記事が1つしかない場合は、「データベース設計をひどく間違ったものにする方法」である必要があります。 ロバートシェルドンから
非常に優れたリソースの幅広いセットを提供するDATAVERSITYブログから始めましょう：
避けるべき主キーと外部キーのエラー
by Michael Blaha | DATAVERSITYブログ| 2015年9月2日
データベース設計エラーの増加–多対多の関係との混同
by Michael Blaha | DATAVERSITYブログ| 2015年9月30日
その他のデータベース設計エラー
by Michael Blaha | DATAVERSITYブログ| 2015年10月26日
Michael Blahaは、3つの記事の素晴らしいセットを寄稿しました。各記事では、データベースモデリングと物理設計のさまざまな落とし穴について説明しています。トピックには、キー、関係、および一般的なエラーが含まれます。また、いくつかの点についてマイケルと話し合っています。キーと人間関係に関する落とし穴を探しているなら、ここから始めるのが良いでしょう。
Blaha氏は、「データベースの約20％が主キールールに違反している」と述べています。わお！これは、データベース開発者の約20％が主キーを適切に作成しなかったことを意味します。この統計が真である場合、それは、モデラーが主キーを定義することを強く「奨励」する、あるいは要求するデータモデリングツールの重要性を実際に示しています。
Blaha氏はまた、「データベースの約50％」に外部キーの問題があるというヒューリスティックを共有しています（彼が研究したレガシーデータベースでの彼の経験によると）。彼は、外部キーを使用するのではなく、あるテーブルから別のテーブルに値を埋め込むことによって、テーブル間の非公式なリンクを回避するように私たちに思い出させます。
私はこの問題を何度も見ました。実装する機能によって非公式のリンクが必要になる可能性があることは認めますが、単純な怠惰が原因で発生することがよくあります。たとえば、何かを変更した人のユーザーIDを表示したい場合は、ユーザーIDをテーブルに直接保存します。しかし、そのユーザーが自分のユーザーIDを変更した場合はどうなりますか？次に、この非公式のリンクが壊れます。これは多くの場合、不十分な設計とモデリングが原因です。
データベースの設計：避けるべき5つの間違い
by Henrique Netzka | DATAVERSITYブログ| 2015年11月2日
この記事には、いくつかの非常に具体的な項目（CLOBにプロトコルを格納する）といくつかの非常に一般的な項目（ローカリゼーションについて考えてください）が含まれていたため、少しがっかりしました。全体的に、記事は問題ありませんが、これらは本当に避けるべき上位5つの間違いですか？私の意見では、リストを作成する必要がある他のいくつかの一般的な間違いがあります。
ただし、前向きな点として、これはグローバリゼーションとローカリゼーションについて意味のある方法で言及している数少ない記事の1つです。私は非常に多言語の環境で働いており、ローカリゼーションのいくつかの恐ろしい実装を見てきました。そのため、この問題が言及されているのを見つけてうれしく思いました。言語列とタイムゾーン列は明白に見えるかもしれませんが、データベースモデルではめったに表示されません。
そうは言っても、（リソースバンドルを使用するのではなく）エンドユーザーが変更できる翻訳を含むモデルを作成するのは興味深いと思いました。少し前に、私はオンライン調査データベースのモデルについて書きました。ここでは、質問と回答の選択肢の簡略化された翻訳をモデル化しました：
エンドユーザーが翻訳を維持できるようにする必要があると仮定すると、推奨される方法は、質問と回答の翻訳テーブルを追加することです。
user_account 日付/時刻をユーザーの現地時間で保存できるようにするためのテーブル：
7つの一般的なデータベース設計エラー
by Grzegorz Kaczor | Vertabeloブログ| 2015年7月17日
ここで少し自己宣伝します。ここには、興味深く魅力的な記事を定期的に投稿するよう努めています。
この特定の記事では、名前付け、索引付け、ボリュームの考慮事項、監査証跡など、いくつかの重要な懸念事項を指摘しています。この記事では、テーブル名に対するOracleの制限など、特定のDBMシステムに関連する問題についても取り上げています。デザイナーが間違いや間違いを犯す方法を説明しているとしても、私は素晴らしい明確な例が本当に好きです。
明らかに、すべての設計エラーをリストすることは不可能であり、リストされたものはあなたのではない可能性があります 最も一般的なエラー。私たちがよくある間違いについて書くとき、それは私たちが描いている他の人の作品で私たちが犯した、または見つけたものです。頻度の観点からランク付けされたエラーの完全なリストは、1人の人がコンパイルすることは不可能です。それにもかかわらず、この記事は潜在的な落とし穴についていくつかの有用な洞察を提供すると思います。それは全体的に素晴らしい堅実なリソースです。
Kaczor氏は彼の記事でいくつかの興味深い点を述べていますが、「ボリュームやトラフィックの可能性を考慮しない」という彼のコメントは非常に興味深いものでした。特に、頻繁に使用されるデータを履歴データから分離することをお勧めします。これは、メッセージングアプリケーションで頻繁に使用するソリューションです。すべてのメッセージの検索可能な履歴が必要ですが、アクセスされる可能性が最も高いメッセージは、過去数日以内に投稿されたメッセージです。したがって、頻繁にアクセスされる「アクティブな」データまたは最近のデータ（非常に少量のデータ）を長期的な履歴データ（大量のデータ）から分割することは、一般的に非常に優れた手法です。
一般的なデータベース設計の間違い
by Troy Blake |シニアDBAブログ| 2015年7月11日
Troy Blakeの記事も優れたリソースですが、この記事の名前を「一般的なSQLServerの設計上の間違い」に変更した可能性があります。
たとえば、「SQL Serverを効果的に使用する場合、ストアドプロシージャは親友です」というコメントがあります。それは問題ありませんが、これは一般的な一般的な間違いですか、それともSQL Serverに固有のものですか？ベンダー固有のストアドプロシージャ、つまりベンダーロックインになってしまうなど、ストアドプロシージャを使用することには不利な点があるため、これを少しSQLServer固有にすることを選択する必要があります。したがって、私はこのリストに「ストアドプロシージャを使用しない」を含めるのが好きではありません。
ただし、良い面として、作者は、計画の不備、見苦しいシステム設計、限られたドキュメント、弱い命名基準、テストの欠如など、いくつかの非常に一般的な間違いを特定したと思います。
したがって、これをSQL Serverの実践者にとって非常に有用なリファレンスとして分類し、他の実践者にとっては有用なリファレンスとして分類します。
7つのデータモデリングの間違い
カート・ケーグル| LinkedIn | 2015年6月12日
Cagle氏のデータベースモデリングの間違いのリストを読むのは本当に楽しかったです。これらは、データベースアーキテクトの視点からのものです。彼は、避けるべき高レベルのモデリングの間違いを明確に特定しています。この全体像を見ると、潜在的なモデリングの混乱を中止できます。
この記事で言及されているタイプのいくつかは他の場所で見つけることができますが、これらのいくつかはユニークです：抽象化が早すぎるか、概念、論理、および物理モデルを混合します。これらは、おそらくより大きなシステムビューではなく、データモデリングプロセスに焦点を合わせているため、他の作成者によって頻繁に言及されることはありません。
特に、「抽象化が早すぎる」の例では、いくつかのサンプル「ストーリー」を作成し、このドメインでどの関係が重要であるかをテストするという興味深い思考プロセスについて説明しています。これは、モデル化されるオブジェクト間の関係に焦点を当てています。その結果、このドメインの重要な関係は何ですかのような質問になります。 ？
この理解に基づいて、個々のドメインアイテムから始めて、それらの上に関係を構築するのではなく、関係を中心にモデルを作成します。私たちの多くはこのアプローチを使用するかもしれませんが、これらのリソースの中で他の著者はコメントしていません。この説明と例は非常に興味深いものでした。
データベース設計をひどく間違ったものにする方法
by Robert Sheldon |簡単な話| 2015年3月6日
これらのリソースの中で読む記事が1つしかない場合は、RobertSheldonの記事である必要があります
この記事で私が本当に気に入っているのは、言及された間違いのそれぞれについて、それを正しく行うためのヒントがあるということです。これらのほとんどは、障害を修正するのではなく回避することに重点を置いていますが、それでも非常に役立つと思います。ここにはほとんど理論がありません。データモデリング中の間違いを回避することについてのほとんどの正解。特定のSQLServerポイントがいくつかありますが、ほとんどの場合、SQL Serverは、エラー回避または障害からの脱出の例を提供するために使用されます。
この記事の範囲も非常に広いです。計画を怠る、ドキュメントに煩わされない、お粗末な命名規則を使用する、正規化に問題がある（多すぎる、または少なすぎる）、キーと制約に失敗する、適切にインデックスを作成しない、実行するなどです。不十分なテスト。
特に、データの整合性に関する実用的なアドバイス、つまりチェック制約を使用する場合と外部キーを定義する場合が気に入りました。さらに、シェルドン氏は、チームが完全性を強制するためにアプリケーションを延期する状況についても説明します。彼は、データベースに複数の方法で、そして多数のアプリケーションからアクセスできると述べているとき、正直に言っています。彼は、「データは、データベース内のデータが存在する場所で保護する必要がある」と結論付けています。これは非常に真実であるため、開発チームやマネージャーに繰り返して、データモデルに整合性チェックを実装することの重要性を説明することができます。
これは私の種類の記事であり、それを支持する多数のコメントに基づいて、他の人が同意していることがわかります。だから、ここでトップマーク。非常に貴重なリソースです。
10の一般的なデータベース設計の間違い
by Louis Davidson |簡単な話| 2007年2月26日
この記事は、多くの一般的な設計ミスをカバーしているので、非常に良いと思いました。意味のあるアナロジー、例、モデル、そしてウィリアムシェイクスピアとJ.R.Rからの古典的な引用さえありました。トールキン。
いくつかの間違いは他の間違いよりも詳細に説明されており、長い例とSQLの抜粋が少し面倒だと感じました。しかし、それは好みの問題です。
ここでも、SQLServerに固有のトピックがいくつかあります。たとえば、データへのアクセスにストアドプロシージャを使用しないという点は、SQLには適していますが、目標が複数のDBMSでのサポートである場合、SPは必ずしも適切ではありません。さらに、汎用T-SQLオブジェクトをコーディングしようとしないように警告されています。 SQL ServerやSybaseを使用することはめったにないため、このヒントは適切ではありませんでした。
このリストはRobertSheldonのものと非常に似ていますが、主にSQL Serverで作業している場合は、いくつかの追加情報があります。
避けるべき5つの単純なデータベース設計エラー
by Anith Sen Larson |簡単な話| 2009年10月16日
この記事では、カバーする単純な設計エラーのそれぞれについて、いくつかの意味のある例を示します。一方、一般的なルックアップテーブル、エンティティ属性値テーブル、属性分割など、同様のタイプのエラーに焦点を当てています。
観察は良好であり、記事にはまれな傾向がある参照さえあります。それでも、より一般的なデータベース設計エラーを見たいと思います。これらのエラーはかなり具体的なように見えましたが、私がすでに書いたように、私たちが書いている間違いは、一般的に私たちが個人的に経験したものです。
私が気に入った項目の1つは、チェック制約を使用する場合と外部キー制約を使用する別のテーブルを使用する場合を決定するための特定の経験則でした。何人かの著者が同様の推奨事項を提供していますが、ラーソン氏はそれらを「必須」、「検討」、「強力なケース」に分類します。「デザインは芸術と科学の混合であり、したがってトレードオフを伴う」と認めています。これは非常に真実だと思います。
最も一般的な物理データベース設計の間違いトップ10
by Craig Mullins |今日のデータとテクノロジー| 2013年8月5日
その名前が示すように、「最も一般的な物理データベース設計の間違いトップ10」は、論理的および概念的な設計ではなく、物理設計に少し重点を置いています。著者のCraigMullinsが言及している間違いはどれも、実際に目立ったり、独特なものではないので、物理的なDBA側で作業している人々にこの情報をお勧めします。
また、説明が少し短いので、特定の間違いが問題を引き起こす理由を理解するのが難しい場合があります。簡単な説明には本質的に問題はありませんが、あまり考える必要はありません。また、例は示されていません。
データ共有の失敗に関して提起された興味深い点が1つあります。この点は他の記事で時々言及されていますが、設計上の間違いではありません。ただし、この問題は、非常によく似た要件に基づいて、新しいチームまたは新製品のためにデータベースが「再作成」されている場合に頻繁に発生します。
。製品チームは、現在のデータベースの「父」にすでに存在するデータを使用したいと思ったことに後で気付くことがよくあります。しかし実際には、彼らは新しい子孫を作るのではなく、親を強化すべきでした。アプリケーションはデータを共有することを目的としています。優れた設計により、データベースをより頻繁に再利用できます。
これらの5つのデータベース設計ミスを犯しますか？
トーマス・ラロック|トーマス・ラロックのブログ| 2012年1月2日
Thomas Larockの質問に答えると、いくつかの興味深い点が見つかるかもしれません。これらの5つのデータベース設計の間違いを犯しますか？
この記事は、キー（外部キー、代理キー、および生成されたキー）にいくらか重きを置いています。ただし、重要な点が1つあります。DBMSの機能がすべてのシステムで同じであると想定してはなりません。これはとても良い点だと思います。また、他のほとんどの記事には見られないものでもあります。おそらく、多くの作成者が主に単一のDBMSに焦点を当てて作業しているためです。
データベースの設計：やりたくない7つのこと
トーマス・ラロック|トーマス・ラロックのブログ| 2013年1月16日
Larock氏は、「やりたくない7つのこと」を書くときに、「5つのデータベース設計の間違い」をいくつか再利用しましたが、ここには他にも良い点があります。
興味深いことに、ラロック氏の指摘のいくつかは他の多くの情報源には見られません。 「パフォーマンスの期待がない」など、かなりユニークな観察結果がいくつか得られます。これは重大な間違いであり、私の経験によれば、非常に頻繁に発生します。アプリケーションコードを開発する場合でも、多くの場合、データモデル、データベース、およびアプリケーション自体が作成された後、人々は非機能要件（非機能テストを作成する必要がある場合）について考え始め、パフォーマンスの期待値を定義し始めます。 。
逆に言えば、「万が一に備えて大きくなる」など、自分のトップ10リストには含めないポイントがいくつかあります。要点はわかりますが、データモデルを作成するときは、リストの上位にはありません。特定のDBMシステムに固有のものはないので、それはボーナスです。
結論として、これらのポイントの多くは、「要件を理解していない」というポイントにカプセル化されている可能性があります。これは、私のトップ10の間違いリストに含まれています。
8つの一般的なデータベース開発ミスを回避する方法
by Base36 | 2012年12月6日
私はこの記事を読むことに非常に興味がありました。しかし、少しがっかりしました。回避についてはあまり議論されておらず、記事のポイントは実際には「これらは一般的なデータベースの間違いである」と「なぜそれらが間違いであるのか」であるように思われます。間違いを回避する方法の説明はあまり目立たない。
さらに、記事の上位8つのエラーのいくつかは実際に争われています。主キーの誤用は一例です。 Base36は、行のアプリケーションデータに基づくのではなく、システムによって生成される必要があることを示しています。私はこれにある程度同意しますが、すべてであるとは確信していません。 PKは常に必要です 生成されます。それは少しカテゴリー的すぎます。
一方、「ハード削除」の間違いは興味深いものであり、他の場所ではあまり言及されていません。ソフト削除は他の問題を引き起こしますが、昨日システム内のどこにデータが移動したかを把握しようとするときに、行を非アクティブとしてマークするだけでも利点があります。トランザクションログを検索することは、1日を楽しく過ごす方法についての私の考えではありません。
データベース設計の七つの大罪
by Jason Tiret |エンタープライズシステムジャーナル| 2010年2月16日
JasonTiretの記事「データベース設計の七つの大罪」を読み始めたときはとても期待していました。ですから、他の多くの記事に見られる間違いをリサイクルするだけではないことを知り、うれしく思いました。それどころか、他のリストにはない「罪」を提供しました。データベースに変更が加えられたときに、データベースの運用後にモデルを更新せずに、すべてのデータベース設計を「前もって」実行しようとしました。 （または、ジェイソンが言うように、「データモデルを生きている呼吸する生物のように扱わない」）。
私はこの間違いを何度も見ました。ほとんどの人は、実際のデータベースと一致しなくなったモデルを更新する必要がある場合にのみ、エラーに気付きます。もちろん、結果は役に立たないモデルです。記事に記載されているように、「変更はモデルに戻る方法を見つける必要があります。」
一方、ジェイソンのリストアイテムの大部分は非常によく知られています。説明は良いですが、例はあまり多くありません。より多くの例と詳細が役立つでしょう。
最も一般的なデータベース設計の間違い
by Brian Prince | eWeek.com | 2008年3月19日
「最も一般的なデータベース設計の間違い」の記事は、実際にはプレゼンテーションの一連のスライドです。いくつかの興味深い考えがありますが、いくつかのユニークなアイテムはおそらく少し難解です。 「RAIDについて知る」や利害関係者の関与などのポイントを念頭に置いています。
一般的に、一般的な問題（計画、命名、正規化、索引）と物理的な詳細に焦点を当てていない限り、これを読書リストに載せることはありません。
10の一般的な設計ミス
by davidm | SQL Serverブログ– SQLTeam.com | 2005年9月12日
「10の一般的な設計ミス」のポイントのいくつかは、興味深く、比較的斬新です。ただし、「NULLの使用」や非正規化など、これらの間違いのいくつかは非常に物議を醸しています。
すべての列をnull許容として作成するのは間違いであることに同意しますが、特定のビジネス機能では、列をnull許容として定義する必要がある場合があります。したがって、それは一般的な間違いと見なすことができますか？そうは思わない。
私が問題にしているもう1つのポイントは、非正規化です。これは必ずしも設計エラーではありません。たとえば、パフォーマンス上の理由から非正規化が必要になる場合があります。
この記事も、詳細と例が大幅に不足しています。 DBAとプログラマーまたはマネージャーとの会話はおもしろいですが、これらのよくある間違いについて、より具体的な例と詳細な正当化をお勧めします。
OTLTとEAV：すべての初心者が犯す2つの大きな設計ミス
by Tony Andrews | Oracleとデータベースに関するTonyAndrews| 2004年10月21日
Andrews氏の記事は、他の記事で言及されている「One True Lookup Table」（OTLT）とEntity-Attribute-Value（EAV）の間違いを思い出させます。このプレゼンテーションの良い点の1つは、これら2つの間違いに焦点を当てているため、説明と例が正確であることです。さらに、一部の設計者がOTLTとEAVを実装する理由についても説明します。
念のために言っておきますが、OTLTテーブルは通常、次のようになり、複数のドメインからのエントリが同じテーブルにスローされます。
いつものように、OTLTが実行可能なソリューションであり、優れたデザインパターンであるかどうかについての議論があります。私は反OTLTグループの側にいると言わなければなりません。これらの表には多くの問題があります。単一の列挙子を使用して、すべての可能な定数のすべての可能な値を表すというアナロジーを使用する場合があります。今のところ、それを見たことがありません。
一般的なデータベースの間違い
by John Paul Ashenfelter |ドブ博士の| 2002年1月1日
Ashenfelter氏の記事には、データベースに関する15の一般的な間違いが記載されています。他の記事で頻繁に言及されていないいくつかの間違いさえあります。残念ながら、説明は比較的短く、例はありません。この記事のメリットは、リストが多くの根拠を網羅しており、回避すべき間違いの「チェックリスト」として使用できることです。これらを最も重要なデータベースの間違いとして分類することはできないかもしれませんが、確かに最も一般的なものの1つです。
ポジティブなことに、これは、日付、通貨、住所などのデータの形式の国際化を処理する必要性について言及している数少ない記事の1つです。ここに例があればいいでしょう。 「Stateがnull許容列であることを確認してください。多くの国では、住所に関連付けられた州はありません。」
この記事の前半で、タイムゾーンや翻訳（ローカリゼーション）など、データベースのグローバリゼーションに備えるための他の懸念事項といくつかのアプローチについて説明しました。通貨と日付の形式の懸念について言及している記事が他にないという事実は厄介です。私たちのデータベースは、私たちのアプリケーションのグローバルな使用のために準備されていますか？
佳作
明らかに、一般的なデータベース設計の間違いやエラーについて説明している記事は他にもありますが、さまざまなリソースの幅広いレビューを提供したいと思います。次のような記事で追加情報を見つけることができます：
10の一般的なデータベース設計の間違い| MISクラスブログ| 2012年1月29日
データベース設計における10のよくある間違い| IDG.se | 2010年6月24日
オンラインリソース：どこから始めればよいですか？どこへ行く？
前述のように、このリストは、データベース設計の誤りやエラーを説明するすべてのオンライン記事を網羅的に調査することを意図したものではありません。むしろ、特に役立つ、または役立つと思われる特定の焦点を持っているいくつかのソースを特定しました。
追加の記事をお気軽にお勧めください。