データベース設計の悪い習慣：あなたはこれらの間違いを犯していますか？

公開: 2022-03-11

開発者として、既存のコードに基づいたタスクが与えられるときはいつでも、多くの課題に直面する必要があります。そのような課題の1つ（多くの場合、最も要求の厳しい課題）には、アプリケーションのデータモデルを理解することが含まれます。

通常、混乱を招くテーブル、ビュー、列、値、ストアドプロシージャ、関数、制約、およびトリガーに直面します。これらは、意味をなすのに長い時間がかかります。そして、そうなると、保存された情報を改善して活用するための多くの方法に気づき始めます。

経験豊富な開発者であれば、最初はもっとうまくできたかもしれないこと、つまり設計上の欠陥にも気付く可能性があります。

この記事では、一般的なデータベース設計の悪い習慣のいくつか、それらが悪い理由、およびそれらを回避する方法について学習します。

悪い習慣その1：データの目的を無視する

データは後で使用するために保存されます。目標は常にデータを保存し、最も効率的な方法で取得することです。これを実現するには、データベース設計者は、データが何を表すのか、どのように取得するのか、どのくらいの速度で、その運用量（つまり、予想されるデータの量）を事前に知っている必要があります。、それがどのように使用されるのか。

たとえば、データが毎日手動で収集される産業情報システムは、情報がリアルタイムで生成される産業システムと同じデータモデルを持ちません。なんで？同じ期間に数百万のレコードを管理する場合と比較して、月に数百または数千のレコードを処理する場合とは大きく異なるためです。データ量が多い場合は、データベースの効率と使いやすさを維持するために、設計者は特別な考慮を払う必要があります。

ただし、もちろん、データの目的は正規化のレベル、データ構造、レコードサイズ、およびシステム全体の一般的な実装にも影響するため、考慮すべき側面はデータ量だけではありません。

したがって、作成するデータシステムの目的を完全に理解することは、データベースエンジンの選択、設計するエンティティ、レコードのサイズと形式、およびデータベースエンジンの管理ポリシーに関する考慮事項につながります。

これらの目標を無視すると、構造的および数学的には正しいものの、基本的に欠陥のある設計になります。

悪い習慣その2：正規化が不十分

データベースの設計は決定論的な作業ではありません。 2人のデータベース設計者は、特定の問題に対するすべてのルールと正規化の原則に従う場合があり、ほとんどの場合、異なるデータレイアウトを生成します。これは、ソフトウェアエンジニアリングの創造的な性質に固有のものです。ただし、すべてのインスタンスで意味のある分析手法がいくつかあり、それらに従うことが、最高のパフォーマンスを発揮するデータベースに到達するための最良の方法です。

それにもかかわらず、正規化の最も基本的なルールに従わずにオンザフライで設計されたデータベースに直面することがよくあります。明確にする必要があります。すべてのデータベースは、少なくとも、第3正規形に正規化する必要があります。これは、エンティティを最もよく表すレイアウトであり、レコードのクエリと挿入、更新、削除の間でパフォーマンスのバランスが最も取れているためです。。

3NF、2NF、さらには1NFに準拠していないテーブルに遭遇した場合は、これらのテーブルを再設計することを検討してください。そうすることに投資する努力は、非常に短期的には報われるでしょう。

悪い習慣3：冗長性

前のポイントと非常に関連しており、正規化の目標の1つはそれを減らすことであるため、冗長性は非常に頻繁に発生するもう1つの悪い習慣です。

冗長なフィールドとテーブルは、同じ情報の多くのバージョンを最新の状態に保つためにビジネスロジックを必要とするため、開発者にとっては悪夢です。これは、正規化ルールに完全に従えば回避できるオーバーヘッドです。冗長性が必要と思われる場合もありますが、将来の開発で考慮に入れるために、非常に特殊な場合にのみ使用し、明確に文書化する必要があります。

冗長性の典型的な悪影響は、データベースサイズの不必要な増加、データの不整合が発生しやすいこと、データベースの効率の低下ですが、さらに重要なことに、データの破損につながる可能性があります。

悪い慣行その4：悪い参照整合性（制約）

参照整合性は、データベースエンジンがデータ品質を最高に保つために提供する最も価値のあるツールの1つです。設計段階から制約が実装されていないか、ほとんど実装されていない場合、データの整合性はビジネスロジックに完全に依存する必要があり、人的エラーの影響を受けやすくなります。

悪い習慣その5：DBエンジンの機能を利用していない

データベースエンジン（DBE）を使用している場合、データ処理タスク用の強力なソフトウェアがあり、ソフトウェア開発を簡素化し、情報が常に正しく、安全で、使用可能であることを保証します。 DBEは次のようなサービスを提供します。

データをすばやく効率的に表示する方法を提供するビュー。通常、データの正確性を失うことなく、クエリの目的でデータを非正規化します。
テーブルのクエリを高速化するのに役立つインデックス。
プログラミングなしで情報を分析するのに役立つ集計関数。
予期しないことが発生した場合にすべて実行され、コミットまたはキャンセル（ロールバック）されるトランザクションまたはデータ変更文のブロック。これにより、情報が永続的に正しい状態に保たれます。
トランザクションの実行中にデータを安全かつ正確に保つロック。
複雑なデータ管理タスクを可能にするプログラミング機能を提供するストアドプロシージャ。
高度な計算とデータ変換を可能にする関数。
データの正確性を保証し、エラーを回避するのに役立つ制約。
データでイベントが発生したときにアクションを自動化するのに役立つトリガー。
内部で実行されるコマンドオプティマイザー（実行プランナー）。すべての文が最高の状態で実行されるようにし、将来の実行計画を維持します。これは、ビュー、ストアドプロシージャ、および関数を使用する最も良い理由の1つです。これらの実行プランは、DBEに永続的に保持されるためです。

これらの機能を知らない、または無視すると、開発は非常に不確実な道に進み、間違いなくバグや将来の問題につながります。

悪い習慣その6：複合主キー

多くのデータベース設計者は、2つ以上のフィールドの組み合わせによって定義される複合フィールドではなく、整数IDの自動生成フィールドを主キーとして使用することについて最近話しているため、これは一種の論争の的となっています。これは現在「ベストプラクティス」として定義されており、個人的には同意する傾向があります。

ただし、これは単なる慣例であり、もちろん、DBEでは複合主キーの定義が許可されています。これは多くの設計者が避けられないと考えています。したがって、冗長性と同様に、複合主キーは設計上の決定事項です。

ただし、複合主キーを持つテーブルに数百万行が含まれると予想される場合、複合キーを制御するインデックスは、CRUD操作のパフォーマンスが大幅に低下するまで大きくなる可能性があることに注意してください。その場合、インデックスが十分にコンパクトになる単純な整数IDの主キーを使用し、一意性を維持するために必要なDBE制約を確立することをお勧めします。

悪い習慣その7：不十分な索引付け

場合によっては、多くの列でクエリを実行する必要があるテーブルがあります。テーブルが大きくなると、これらの列のSELECTが遅くなることがわかります。テーブルが十分に大きい場合は、論理的には、このテーブルにアクセスするために使用する各列にインデックスを作成して、SELECTのパフォーマンスは向上するが、INSERT、UPDATE、およびDELETEが低下することをほぼ即座に見つけることができます。もちろん、これは、インデックスをテーブルと同期させておく必要があるためです。これは、DBEにとって大きなオーバーヘッドを意味します。これは、さまざまな方法で解決できるオーバーインデックスの典型的なケースです。たとえば、テーブルのクエリに使用する主キーとは異なるすべての列に1つのインデックスしかない場合、これらの列を使用頻度の高いものから低いものの順に並べると、すべてのCRUD操作で列ごとに1つのインデックスよりもパフォーマンスが向上する可能性があります。

一方、クエリに使用される列にインデックスがないテーブルがあると、ご存知のとおり、SELECTのパフォーマンスが低下します。

また、インデックスの効率は列の種類によって異なる場合があります。 INT列のインデックスは可能な限り最高のパフォーマンスを示しますが、VARCHAR、DATE、またはDECIMAL（意味がある場合）のインデックスはそれほど効率的ではありません。この考慮事項は、可能な限り最高の効率でアクセスする必要があるテーブルの再設計につながる可能性さえあります。

したがって、インデックス作成は常に微妙な決定です。インデックス作成が多すぎると、少なすぎるほど悪くなる可能性があり、インデックスを作成する列のデータ型が最終結果に大きな影響を与えるためです。

悪い習慣その8：不十分な命名規則

これは、プログラマーが既存のデータベースに直面するときに常に苦労することです。多くの場合、他の方法がないため、テーブルと列の名前でデータベースに格納されている情報を理解します。

テーブル名は、それが保持するエンティティを説明する必要があり、各列名は、それが表す情報を説明する必要があります。これは簡単ですが、テーブルを相互に関連付ける必要がある場合は複雑になり始めます。名前は乱雑になり始め、さらに悪いことに、非論理的な規範と混同する命名規則がある場合（たとえば、「列名は8文字以下でなければならない」など）。最終的な結果として、データベースが読み取れなくなります。

したがって、データベースがサポートするアプリケーションとともに存続し、進化することが期待される場合は、命名規則が常に必要です。簡潔で、シンプルで、読みやすいものを確立するためのガイドラインを次に示します。

テーブルまたは列の名前のサイズに制限はありません。誰も覚えたり理解したりしない頭字語よりも、わかりやすい名前を付ける方がよいでしょう。
等しい名前は同じ意味を持ちます。同じ名前で、タイプや意味が異なるフィールドは避けてください。これは遅かれ早かれ混乱するでしょう。
必要な場合を除いて、冗長にしないでください。たとえば、テーブル「Item」では、「ItemName」、「PriceOfItem」、または同様の名前のような列を持つ必要はありません。「名前」と「価格」で十分です。
DBEの予約語に注意してください。列をSQL予約語である「Index」と呼ぶ場合は、「IndexNumber」などの別の列を使用してみてください。
単純な主キールール（自動生成された単一の整数）に固執する場合は、すべてのテーブルで「Id」という名前を付けます。
別のテーブルに結合する場合は、必要な外部キーを「Id」という名前の整数の後に結合されたテーブルの名前（IdItemなど）を付けて定義します。
制約に名前を付ける場合は、制約を説明する接頭辞（たとえば、「PK」または「FK」）を使用し、その後に関連する1つまたは複数のテーブルの名前を続けます。もちろん、アンダースコア（ "_"）を控えめに使用すると、読みやすくなります。
インデックスに名前を付けるには、プレフィックス「IDX」の後にテーブル名とインデックスの1つまたは複数の列を使用します。また、インデックスが一意の場合はプレフィックスまたはサフィックスとして「UNIQUE」を使用し、必要に応じてアンダースコアを付けます。

インターネット上には、データベース設計のこの非常に重要な側面にさらに光を当てる多くのデータベース命名ガイドラインがありますが、これらの基本的なガイドラインを使用すると、少なくとも読み取り可能なデータベースに到達できます。ここで重要なのは、命名ガイドラインのサイズや複雑さではなく、ガイドラインに従う際の一貫性です。

いくつかの最後の発言

データベース設計は知識と経験の組み合わせです。ソフトウェア業界は、初期の頃から大きく進化してきました。幸いなことに、データベース設計者が最良の結果を達成するのに役立つ十分な知識があります。

インターネット全体に優れたデータベース設計ガイドラインがあり、データベース設計では悪い習慣や避けるべきことがあります。ただあなたのピックを取り、それに固執してください。

そして、忘れないでください、それはあなたが学ぶのは実験、間違い、そして成功を通してのみです、それで先に進んで今始めてください。