290

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

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

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

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

  • 階層データの保存 (例: タイプを持つ単一のテーブル vs 1:1 のキーと違いを持つ複数のテーブル...)
  • 可変構造でデータを保存する (例: 一般列 vs xml vs 区切り列...)
  • データの非正規化 (影響を最小限に抑える方法など)
4

6 に答える 6

163

Martin Fowler の Signature Series にRefactoring Databasesという本があります。これは、データベースをリファクタリングするためのテクニックのリストを提供します。データベース パターンのリストをこれほど聞いたことがあるとは言えません。

また、David C. Hay のData Model Patternsと、最初のパターンに基づいて構築された、はるかに野心的で興味をそそるA Metadata Mapのフォローアップを強くお勧めします。序文だけでも啓発的です。

Len Silverston の Data Model Resource Book Series も、事前に準備されたデータベース モデルを探すのに最適な場所です。Volume 1には、普遍的に適用可能なデータ モデル (従業員、アカウント、出荷、購入など) が含まれており、Volume 2には、業界固有のデータ モデル (会計、第 3 巻では、データ モデル パターンを提供します。

最後に、この本は表向きは UML とオブジェクト モデリングに関するものですが、Peter Coad のModeling in Color With UMLは、オブジェクト/データ モデルには 4 つのコア アーキタイプがあるという前提から始まるエンティティ モデリングの「アーキタイプ」主導のプロセスを提供します。

于 2008-09-28T11:44:48.520 に答える
48

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

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

パターンは自明に再利用可能ではありません。ただし、パターンに従ってダウンデザインを実装できます。

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

  1. 外部キーを使用した 1 対多の関係 (主従関係、親子関係)。

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

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

  4. スター スキーマ: 次元と事実、OLAP 設計。

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

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

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

  8. ユニテーブル。[これをアンチパターンと呼ぶ人もいます。] これは、第 2 正規形と第 3 正規形に違反する事前に結合されたものがたくさんあるテーブルです。

  9. 配列テーブル。これは、列に値の配列またはシーケンスを使用することにより、第 1 正規形に違反するテーブルです。

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

データベースを設計するほとんどの人は、「これもその 1 つです」と 6 ダースほど簡単にガタガタ鳴らすことができます。これらは、彼らが定期的に使用する設計パターンです。

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

于 2008-09-28T13:36:52.167 に答える
6

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

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

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

于 2008-10-10T09:19:17.710 に答える
4

何年にもわたるデータベース開発の結果、始める前に答えなければならないいくつかの疑問や質問があると言えます。

質問:

  • 将来、別の DBMS を使用しますか? はいの場合、現在の DBMS の特殊な SQL を使用しないでください。アプリケーションのロジックを削除します。

使用禁止：

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

推奨事項:

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

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

于 2008-09-28T11:55:34.470 に答える
1

あなたの質問は少し漠然としていますUPSERTが、デザインパターンと見なすことができると思います. MERGEを実装していない言語の場合、問題を解決するための代替手段がいくつかあります(適切な行が存在する場合はUPDATE; そうでINSERTない場合)。

于 2008-09-28T12:18:05.930 に答える
1

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

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

データベース オブジェクトの命名を考えている場合、それは設計自体ではなく、規則のカテゴリに属します。

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

于 2008-09-30T04:12:35.097 に答える