リレーショナルデータベースの設計パターン？[閉まっている]

デザインパターンは通常、オブジェクト指向のデザインに関連しています。リレーショナルデータベースを作成およびプログラミングするための設計パターン
はありますか？
多くの問題には、必ず再利用可能な解決策が必要です。

例には、テーブルデザイン、ストアドプロシージャ、トリガーなどのパターンが含まれます。

martinfowler.comのような、そのようなパターンのオンラインリポジトリはありますか？

パターンが解決できる問題の例：

• 階層データの保存（例：タイプが1つのテーブルと1：1のキーと相違がある複数のテーブル...）
• 可変構造でデータを保存する（例：汎用列vs xml vs区切り列...）
• データを非正規化する（影響を最小限に抑える方法など...）

マーティンファウラーの署名シリーズに、リファクタリングデータベースと呼ばれる本があります。これは、データベースをリファクタリングするためのテクニックのリストを提供します。データベースのパターンのリストをあまり聞いたとは言えません。

また、David C. HayのデータモデルパターンとフォローアップのAメタデータマップを強くお勧めします。メタデータマップは、最初に構築され、より野心的で興味深いものです。序文だけでも啓蒙的です。

また、いくつかの事前に用意されたデータベースモデルを探すのに最適な場所は、Len Silverstonのデータモデルリソースブックシリーズボリューム1には普遍的に適用可能なデータモデル（従業員、アカウント、配送、購入など）が含まれ、ボリューム2には業界固有のデータモデル（会計、ヘルスケアなど）、ボリューム3はデータモデルパターンを提供します。

最後に、この本は表面的にはUMLとオブジェクトモデリングについてですが、Peter CoadのUMLによるカラーモデリングは、オブジェクト/データモデルには4つのコアアーキタイプがあるという前提から、エンティティモデリングの「アーキタイプ」主導型プロセスを提供します。

デザインパターンは、簡単に再利用できるソリューションではありません。

定義上、デザインパターンは再利用可能です。これらは、他の優れたソリューションで検出されるパターンです。

パターンは簡単には再利用できません。ただし、パターンに従ってダウンデザインを実装できます。

リレーショナルデザインパターンには、次のようなものが含まれます。

1. 外部キーを使用した1対多の関係（マスター/詳細、親子）関係。

2. ブリッジテーブルとの多対多の関係。

3. FK列のNULLで管理されるオプションの1対1の関係。

4. Star-Schema：ディメンションとファクト、OLAPデザイン。

5. 完全に正規化されたOLTP設計。

6. ディメンション内の複数のインデックス付き検索列。

7. 1つ以上のアプリケーションで使用されるPK、説明、およびコード値を含む「ルックアップテーブル」。なぜコードがあるのですか？わかりませんが、使用する必要がある場合、これはコードを管理する方法です。

8. ユニテーブル。[これをアンチパターンと呼ぶ人もいます。これはパターンであり、時には悪いこともあり、良いこともあります。

9. 配列テーブル。これは、列に値の配列またはシーケンスがあることにより、最初の正規形に違反するテーブルです。

10. 混合データベース。これはトランザクション処理用に正規化されたデータベースですが、レポートと分析のための追加のインデックスがたくさんあります。これはアンチパターンです。これを行わないでください。人々はとにかくそれをするので、それはまだパターンです。

データベースを設計するほとんどの人々は、半ダースの「それはそれらの別のものです」を容易に打ち負かすことができます。これらは、定期的に使用するデザインパターンです。

また、これには、使用と管理の管理上および運用上のパターンは含まれません。

AskTomは、おそらくOracle DBのベストプラクティスに関する単一の最も役立つリソースです。（通常、特定のトピックに関するGoogleクエリの最初の単語として「asktom」と入力します）

リレーショナルデータベースでデザインパターンについて話すことは、本当に適切だとは思いません。リレーショナルデータベースはすでに問題に「設計パターン」を適用しています（問題は「データの整合性を維持しながらデータを表現、保存、処理する方法」であり、設計はリレーショナルモデルです）。他のアプローチ（一般的には廃止と見なされています）は、ナビゲーションモデルと階層モデルです（他にも多くのモデルが存在します）。

そうは言っても、「データウェアハウジング」は、データベース設計におけるやや別個の「パターン」またはアプローチと考えるかもしれません。特に、スタースキーマについて読むことに興味があるかもしれません。

長年のデータベース開発の後、私は始める前にいくつかのノーゴーといくつかの質問があると言うことができます：

質問：

• 今後、別のDBMSで使用しますか？はいの場合、現在のDBMSの特別なSQL要素を使用しません。アプリケーションのロジックを削除します。

使用しない：

• テーブル名と列名の空白
• テーブル名と列名の非ASCII文字
• 特定の小文字または大文字へのバインド。また、小文字と大文字のみが異なる2つのテーブルまたは列を使用しないでください。
• 「FROM」、「BETWEEN」、「DELETE」などのテーブルまたは列名にSQLキーワードを使用しない

おススメ：

• ユニコードのサポートにはNVARCHARまたは同等のものを使用してください。そうすれば、コードページに問題はありません。
• すべての列に一意の名前を付けます。これにより、結合を容易にして列を選択できるようになります。すべてのテーブルに「ID」、「名前」、または「説明」の列がある場合は非常に困難です。XyzIDとAbcIDを使用します。
• 複雑なSQL式には、リソースバンドルまたは等しいを使用します。別のDBMSに簡単に切り替えることができます。
• どのデータ型にも強くキャストしません。別のDBMSはこのデータ型を持つことができません。FOrの例OracleはSMALLINTだけを持っているわけではありません。

これが良い出発点であることを願っています。

あなたの質問は少し曖昧ですが、私はUPSERTデザインパターンと考えることができると思います。実装していない言語の場合MERGE、問題を解決するための選択肢の数を（適切な行が存在する場合はUPDATE、そうでないINSERTが存在）。

意味はパターンによって異なります。人/会社/トランザクション/製品などを考えているのであれば、はい-すでに多くの汎用データベーススキーマが利用可能です。

Factory、Singletonを考えている場合は...いいえ、DBプログラミングには低レベルであるため、これらは必要ありません。

データベースオブジェクトの名前付けを考えている場合は、それ自体がデザインではなく、規則の範疇に属しています。

ところで、S.Lott、1対多および多対多の関係は「パターン」ではありません。これらは、リレーショナルモデルの基本的なビルディングブロックです。