36

「パーティモデル」は、リレーショナルデータベース設計の「パターン」です。その少なくとも一部には、顧客、従業員、パートナーなどの多くのエンティティ間の共通性を見つけ、それをより「抽象的な」データベーステーブルに組み込むことが含まれます。

以下についてのご意見をお聞かせください。

  1. パーティーモデルの背後にあるコア原則と動機付けの力は何ですか？
  2. データモデルに対して何をするように規定していますか？（上記の私のビットはかなり高レベルであり、いくつかの点でおそらく正しくありません。私はそれを使用したプロジェクトに取り組んできましたが、他の問題に焦点を当てた別のチームと協力していました）。
  3. あなたの経験から、それについてどのように感じましたか？使用しましたか？使用した場合は、もう一度使用しますか？長所と短所は何でしたか？
  4. パーティーモデルはORMの選択を制限しましたか？たとえば、ドメインオブジェクトと物理データモデルの間に十分な「抽象化レイヤー」がないため、特定のORMを削除する必要がありましたか？

すべての回答がこれらの質問のすべてに対応するわけではないと確信しています...しかし、それらの1つ以上に触れることは、私が直面しているいくつかの決定を下すのに役立ちます。

ありがとう。

4

6 に答える 6

25
  1. 政党モデルの背後にある核となる原則と原動力は何ですか?

私が使用した範囲では、主にコードの再利用と柔軟性に関するものです。以前にゲスト/ユーザー/管理モデルで使用したことがあり、ユーザーをあるグループから別のグループに移動する必要がある場合に、その価値が確かに証明されています. これを拡張して、組織や企業をその下のユーザーで表現すると、SQL に特に固有ではない抽象化の形式が実際に提供されます。

  1. データモデルに対して何をするように規定していますか? (上記の私のビットはかなり高レベルであり、いくつかの点で間違っている可能性があります。私はそれを使用するプロジェクトに参加していましたが、他の問題に焦点を当てた別のチームと協力していました)。

もう少し詳細が必要ですが、上記のビットはかなり正しいです。データベース内のエンティティ (当事者と呼びます) が別の当事者と契約し、それが下請け契約を結ぶ状況を想像することができます。パーティーは、従業員、請負業者、または会社である可能性があり、すべてパーティーのサブクラスです。私の理解では、Party テーブルがあり、次に各サブクラスのより具体的なテーブルがあり、さらにサブクラス化できます (Party -> Person -> Contractor)。

  1. あなたの経験は、あなたがそれについて感じるように導きましたか? 使用しましたか。使用した場合、もう一度使用しますか。長所と短所は何でしたか？

システムに新しいタイプを柔軟に追加し、最初は予想もしていなかったタイプ間の関係を作成し、設計する必要がある場合 (ユーザーが新しいレベルに移行する、企業が他の企業を雇用するなど)、これには利点があります。また、単一のクエリを実行して、複数のタイプの関係者 (会社、従業員、請負業者) のデータを取得できるという利点もあります。反対に、実際に必要なデータを取得するために抽象化のレイヤーを追加し、特定の型をクエリするときにデータベースの負荷 (または少なくとも結合の数) を増やしています。抽象化が行き過ぎた場合、複雑さが可読性とデータベースの負荷に悪影響を及ぼし始めるため、データを取得するために複数のクエリを実行する必要が生じる可能性があります。

  1. パーティ モデルによって ORM の選択が制限されましたか? たとえば、特定の ORM を排除する必要があったのは、ドメイン オブジェクトと物理データ モデルの間に十分な「抽象化レイヤー」を確保できなかったからですか?

これは確かに私が少し苦手な領域ですが、アプリケーション層でビューとミラー化された抽象化を使用しても、それほど大きな問題にはならないことがわかりました。私にとっての本当の問題は、データソースを直接読みたいときの「データXの一部はどこにあるのか」ということでした(システムの新しい開発者にとっても常に直感的であるとは限りません)。

于 2009-04-04T06:15:52.677 に答える
12

パーティ モデル (別名エンティティ スキーマ) の背後にある考え方は、スキーマフリー データベースのスケーラビリティの利点を活用するデータベースを定義することです。パーティ モデルは、エンティティごとに 1 つのテーブルではなく、エンティティをパーティ タイプ レコードとして定義することによってこれを行います。その結果、テーブルがほとんどなく、格納されているデータの意味に関する知識がほとんどない、非常に正規化されたデータベースが作成されます。そのすべての知識は、コード内のデータ アクセスにプッシュされます。パーティ モデルを使用したデータベースのアップグレードは、スキーマが変更されないため、最小限またはまったくありません。これは基本的に、派手な名前といくつかの追加の属性を備えた、美化されたキーと値のペアのデータ モデル構造です。

長所：

  • 素晴らしい水平スケーラビリティ。エンティティ モデルで 5 ～ 6 個のテーブルを定義したら、ビーチに行ってマルガリータを飲むことができます。このデータベースは、最小限の労力で必要なだけ仮想的にスケールアウトできます。
  • データベースは、あなたが投げたあらゆるデータ構造をサポートします。また、アプリケーションに影響を与えずに、データ構造とパーティ/エンティティの定義をオンザフライで変更することもできます。これは非常に強力です。
  • スキーマを変更するのではなく、レコードを追加することで、任意のデータ エンティティをモデル化できます。つまり、スキーマ移行スクリプトに別れを告げることができます。
  • これはプログラマーにとって楽園です。彼らが書くコードは、コードで使用する実際のエンティティを定義し、オブジェクトからテーブルなどへのマッピングがないからです。Party テーブルは、選択したフレームワークのベース オブジェクト (.NET の System.Object) と考えることができます。

短所：

  • パーティー/エンティティ モデルは ORM とはうまく連携しないため、エンティティ データベースから意味的に意味のあるエンティティを取得するために EF や NHibernate を使用することは忘れてください。
  • たくさんの結合。パフォーマンス チューニングの課題。この「短所」は、エンティティを定義するために使用する慣行に関連していますが、夜に悪夢をもたらすような気が遠くなるようなクエリをより多く実行することになると言っても過言ではありません。
  • 消費しにくい。ビジネスに慣れていない開発者や DB の専門家は、これらのモデルによって公開されるエンティティに慣れるのに苦労するでしょう。すべてが抽象的であるため、データベースの上に構築して他の人に何が保存されているかを説明できる図や視覚化はありません。
  • 負荷の高いデータ アクセス モデルまたはビジネス ルール エンジンが必要になります。基本的に、ある時点でデータベースに何を求めているのかを理解する作業を行う必要があり、データベース モデルは今回は役に立ちません。

リレーショナル データベースのパーティ スキーマまたはエンティティ スキーマを検討している場合は、NoSql データ ストア、BigTable、KV ストアなどの他のソリューションを検討する必要があります。この動きの先駆者である MongoDB、DynamoDB、Cassandra など、大規模な展開とトラクションを備えた優れた製品がいくつかあります。

于 2012-09-27T19:20:49.843 に答える
2

私が 1980 年代初頭にこれらのアイデアを実装するチームの一員だったとき、ORM はまだ発明されていなかったので、ORM の選択が制限されることはありませんでした。

その特定のプロジェクトは、私がこれまでに見た「革命的な」アイデアの中で最も説得力のある概念実証の 1 つであったため、私はいつでもそれらのアイデアに頼っていました (当時は確かにそうでした)。

それはあなたを何も強制しません。そして、それはあなたを何からも止めません（つまり、間違いから）。独自の情報モデルを定義するのはあなたです。

すべてのパーティには多くの共通のプロパティがあります。それらが名前などを持っているという事実（私たちはそれらを「シグナル」と呼びました）。「住所」と呼ばれる主要/主要な場所があるという事実。彼ら全員が、ある意味でビジネスの契約に関与しているという事実。

于 2009-06-08T23:56:28.597 に答える
1

これは広大なトピックです。LenSilverstonとPaulAgnewによるTheDataModel Resource Book Volume 3-Universal Patterns forDataModelingを読むことをお勧めします。

私はちょうど私のコピーを受け取りました、そしてそれはかなり良いです-それはハイブリッドコンテキストロールパターンなどを含むデータモデリングへの多くのアプローチの見落としをあなたに提供します。すべてのアプローチの詳細な長所と短所があります。

パーティの関係と役割をすべて長所と短所でモデル化する方法はたくさんあります。回答として受け入れられた質問は、「パーティモデル」の1つのインスタンスのみを対象としています。

たとえば、多くのアプローチでは、「従業員」、「プロジェクトマネージャー」などの概念は、特定のコンテキスト内でパーティが果たすことができる役割です。家に帰ったら、もっと良い内訳を教えようと思います。

于 2009-05-04T10:31:42.393 に答える
-1

よくわかりませんが、パーティ モデルは一般化-専門化パターンの特定のケースのように思えます。「汎化特化リレーショナル モデリング」で検索すると、興味深い記事がいくつか見つかります。

于 2009-04-04T19:07:41.167 に答える