「パーティモデル」の背後にある原則とその利点は何ですか？
「パーティモデル」は、リレーショナルデータベース設計の「パターン」です。その少なくとも一部には、顧客、従業員、パートナーなどの多くのエンティティ間の共通性を見つけ、それをいくつかのより「抽象的な」データベーステーブルに組み込むことが含まれます。
以下についてのご意見をお聞かせください。
- 党モデルの背後にあるコア原則と動機付けの力は何ですか？
- データモデルに対して何をするように規定していますか？ （上記の私のビットはかなり高レベルであり、いくつかの点でおそらく正しくありません。私はそれを使用したプロジェクトに取り組んできましたが、他の問題に焦点を当てた別のチームと協力していました）。
- あなたの経験から、それについてどのように感じましたか？使用しましたか？使用した場合は、もう一度使用しますか？長所と短所は何でしたか？
- パーティーモデルはORMの選択を制限しましたか？たとえば、ドメインオブジェクトと物理データモデルの間に十分な「抽象化レイヤー」がないため、特定のORMを削除する必要がありましたか？
すべての回答がこれらの質問のすべてに対応するわけではないと確信しています...しかし、それらの1つ以上に触れることは、私が直面しているいくつかの決定を下すのに役立ちます。
ありがとう。
- 党モデルの背後にあるコア原則と動機付けの力は何ですか？
私が使用した範囲では、それは主にコードの再利用と柔軟性に関するものです。以前、guest/user/adminモデルで使用しましたが、ユーザーをあるグループから別のグループに移動する必要がある場合に、その価値を確実に証明します。これを拡張して、組織や企業をその下のユーザーで表すようにします。これは、SQLに特に固有ではない抽象化の形式を実際に提供します。
- データモデルに対して何をするように規定していますか？ （上記の私のビットはかなり高レベルであり、いくつかの点でおそらく正しくありません。私はそれを使用したプロジェクトに取り組んできましたが、他の問題に焦点を当てた別のチームと協力していました）。
あなたは上記のビットでかなり正しいですが、それはもう少し詳細が必要です。データベース内のエンティティ（パーティと呼びます）が別のパーティに契約し、それが下請けにつながる状況を想像できます。パーティーは、パーティーのすべてのサブクラスである従業員、請負業者、または会社である可能性があります。私の理解では、Partyテーブルがあり、サブクラスごとにさらに具体的なテーブルがあり、さらにサブクラス化できます（Party-> Person-> Contractor）。
- あなたの経験から、それについてどのように感じましたか？使用しましたか？使用した場合は、もう一度使用しますか？長所と短所は何でしたか？
システムに新しいタイプを柔軟に追加し、当初は予期していなかったタイプとアーキテクト（ユーザーが新しいレベルに移行する、企業が他の企業を採用するなど）の間に関係を作成する必要がある場合に利点があります。また、単一のクエリを実行し、複数のタイプの関係者（会社、従業員、請負業者）のデータを取得するという利点もあります。反対に、実際に必要なデータに到達するために抽象化レイヤーを追加し、特定のタイプを照会するときにデータベースの負荷（または少なくとも結合の数）を増やしています。抽象化が行き過ぎた場合、複雑さが読みやすさとデータベースの負荷に悪影響を及ぼし始めるため、データを取得するために複数のクエリを実行する必要があります。
- パーティーモデルはORMの選択を制限しましたか？たとえば、ドメインオブジェクトと物理データモデルの間に十分な「抽象化レイヤー」がないため、特定のORMを削除する必要がありましたか？
これは確かに少し弱い分野ですが、アプリケーション層でビューとミラー化された抽象化を使用しても、これはそれほど問題にはならないことがわかりました。私にとっての本当の問題は、データソースを直接読み取りたいときに、常に「データXがどこにあるのか」ということでした（システムの新しい開発者にとっても、常に直感的であるとは限りません）。
パーティモデル（別名エンティティスキーマ）の背後にある考え方は、スキーマフリーデータベースのスケーラビリティの利点のいくつかを活用するデータベースを定義することです。パーティモデルは、エンティティごとに1つのテーブルではなく、エンティティをパーティタイプのレコードとして定義することでこれを実現します。その結果、非常に正規化されたデータベースが作成され、テーブルがほとんどなく、格納するデータの意味に関する知識もほとんどありません。その知識はすべて、コード内のデータアクセスにプッシュされます。スキーマが変更されることはないため、パーティモデルを使用したデータベースのアップグレードは最小限からゼロになります。これは本質的に、いくつかの派手な名前といくつかの追加の属性を備えた、栄光に満ちたキーと値のペアのデータモデル構造です。
長所：
- キックアスの水平方向のスケーラビリティ。エンティティモデルで5〜6個のテーブルを定義したら、ビーチに行ってマルガリータを飲むことができます。このデータベースは、最小限の労力で必要なだけ仮想的にスケールアウトできます。
- データベースは、スローするすべてのデータ構造をサポートします。アプリケーションに影響を与えることなく、データ構造とパーティ/エンティティの定義をその場で変更することもできます。これは非常に強力です。
- スキーマを変更せずにレコードを追加することで、任意のデータエンティティをモデル化できます。つまり、スキーマ移行スクリプトに別れを告げることができます。
- これはプログラマーのパラダイスです。なぜなら、彼らが書くコードは、コードで使用する実際のエンティティを定義し、オブジェクトからテーブルなどへのマッピングがないからです。 Partyテーブルは、選択したフレームワークのベースオブジェクト（System.Object for .NET）と考えることができます。
短所：
- パーティ/エンティティモデルはORMとうまく連携しないため、EFまたはNHibernateを使用してエンティティデータベースから意味的に意味のあるエンティティを取得することを忘れてください。
- たくさんの結合。パフォーマンスチューニングの課題。この「短所」は、エンティティを定義するために使用する慣行に関連していますが、夜に悪夢をもたらすような心を曲げるクエリをさらに多く実行することになると言っても過言ではありません。
- 消費しにくい。あなたのビジネスに不慣れな開発者やDBのプロは、これらのモデルによって公開されているエンティティに慣れるのに苦労するでしょう。すべてが抽象的であるため、データベースの上に構築して、他の人に何が保存されているかを説明するための図や視覚化はありません。
- 重いデータアクセスモデルまたはビジネスルールエンジンが必要になります。基本的に、ある時点でデータベースに何を求めているかを理解する作業を行う必要がありますが、今回はデータベースモデルが役に立ちません。
リレーショナルデータベースのパーティスキーマまたはエンティティスキーマを検討している場合は、NoSqlデータストア、BigTable、KVストアなどの他のソリューションを検討する必要があります。 MongoDB、DynamoDB、この動きの先駆者であるCassandra.
私が1980年代初頭にこれらのアイデアを実装したチームの一員だったとき、ORMはまだ発明されていなかったため、ORMの選択を制限することはありませんでした。
その特定のプロジェクトは、私がこれまでに見た中で最も説得力のある概念実証の1つであったため、いつでもこれらのアイデアに頼ることになります（確かに当時はそうでした）。
それはあなたに何も強制しません。そして、それはあなたを何からも止めません（どんな間違いからでも、つまり）。あなた自身の情報モデルを定義するのはあなたです。
すべての当事者には、多くの共通の特性があります。それらが名前などを持っているという事実（私たちはそれらを「シグナル」と呼びました）。それらが「アドレス」と呼ばれるプリンシパル/プライマリロケーションを持っているという事実。それらすべてが、ある意味で、ビジネスの契約に関与しているという事実。
よくわかりませんが、パーティモデルは一般化-特殊化パターンの特定のケースのように聞こえます。 「一般化特殊化リレーショナルモデリング」を検索すると、興味深い記事がいくつか見つかります。
これは広大なトピックです。LenSilverstonとPaulAgnewによる データモデルリソースブック第3巻-データモデリングのユニバーサルパターン を読むことをお勧めします。
私はちょうど私のコピーを受け取りました、そしてそれはかなり良いです-それはハイブリッドコンテキストロールパターンなどを含むデータモデリングへの多くのアプローチの見落としをあなたに提供します。すべてのアプローチの詳細な長所と短所があります。
パーティの関係と役割をすべてメリットとデメリットでモデル化する方法はたくさんあります。回答として受け入れられた質問は、「パーティモデル」の1つのインスタンスのみを対象としています。
たとえば、多くのアプローチでは、「従業員」、「プロジェクトマネージャー」などの概念は、パーティが特定のコンテキスト内で果たすことができる役割です。家に帰ったら、もっと良い内訳を教えようと思います。
私の理解からの簡単な話として：パーティモデリングは柔軟性を提供し、実装するにはより多くの労力（T-sql結合など）が必要です。
また、「パーティモデリング（シリアル化/一般化）を使用すると、他のテーブルに対してFK-Relationを使用できるようになります」と指摘したいと思います。例：Userテーブルに一般化されたさまざまなタイプのユーザー（admin、user、...）を考えてみてください。そうすれば、UserIDテーブルにAuthorizationを含めることができます。