問題タブ [class-table-inheritance]

symfony2 の「クラス テーブル継承」モデルを使用して、継承を伴うデータベース モデルがあります。

Employee は、最上位の継承モデルである抽象クラスです。

秘書は従業員を拡張する子です。Technician は、Employee を拡張する子でもあります。

秘書が技術者のためにいくつかのことを管理できるアプリケーションを構築しているため、秘書にはフォームなどを備えた管理パネルがあります。

SecretRepository は、秘書がアプリケーションを介して認証できるようにする UserProvider インターフェイスでもあります。

私が抱えている問題は、認証クエリが識別子を気にしないことです...

認証 SQL クエリのデバッグ

秘書と従業員の関係を管理する方法がわかりませんか？秘書から従業員への外部キーを手動で含める必要がありますか? または、認証クエリの識別子を手動で処理する必要がありますか?

私のモデルの基本を見てみましょう:

親クラスの従業員

子クラス書記

UserProviderInterfaceクラスのSecretRepository

問題は単純です。INNER JOIN 句は正しくありません。なぜなら、秘書から従業員への外部キーを使用せず、技術者 ID にもなり得る直接 ID を使用するからです。

これは私のテーブルのいくつかの行のエクスポートです:

私は、Jeff Smith の「SQL Server でのテーブル継承の実装」で説明されている手法に従っています(これは、この種の構造を実装するための事実上のアプローチのようです)。実表には、その3 つのサブタイプ表、、Peopleと 1 : 0..1 の関係があります。これは、従来、サブタイプ テーブルの主キーをベース テーブルへの外部キーとして定義することによって行われていました。StudentsTeachersParents

サブタイプ間で排他性を強制する (同じ人が同時に生徒と教師になるのを防ぐ) ために、作成者PersonTypeIDは永続化された計算列として各サブタイプ テーブルに追加し、それをベース テーブルの外部キー制約に含めることをお勧めします。

ただし、このアプローチには多くの問題があります。

1. 各サブタイプ テーブルで追加の列を無駄にします。
2. 実表に一意制約を追加する必要があります。これにより、より多くのスペースが浪費され (一意のインデックスとして実装されるため)、ベース テーブルへの更新が遅くなります。
3. 外部キー制約には、(1 つではなく) 2 つの列のチェックが含まれるため、サブタイプ テーブルへの更新が遅くなります。

私の仮説は、代わりにスカラー関数を介してチェック制約を使用して一意性を強制する方がよいというものです。これにより、余分な列と一意のインデックスのための無駄なストレージがなくなり、ベース テーブルへの更新が高速化され、複合外部キーと同じパフォーマンスがサブタイプ テーブルへの更新で達成される可能性があります。

このアプローチを使用しない理由はありますか?

Class Table Inheritance を使用して Person を拡張し、Employee と Dragon を追加できるようにします。

人、従業員、ドラゴンはすべておもちゃを持つことができます。

Person、Employee、Dragon、Toys をどのように関連付けるべきか?

クラス テーブル継承の利点は、PersonToy、EmployeeToy、DragonToy と呼ばれる新しいエンティティの作成を回避して、親エンティティ (Person) に関係を設定できることです。

すべてが機能するよう$toy->setEmployee($employee)にコードを記述できれば理想的です。 $toy->setDragon($dragon)setPerson()

反対側では、$toy->getDragon() と $toy->getEmployee() を呼び出して、Person ではなく Dragon/Employee を取得できます。

Entity Toy は Person とのみ関係があることを理解していますが、Person は拡張され、Dragon または Employee になる可能性があります。

可能であれば、これをどのように達成できますか?

ここで説明されているように、クラステーブルの継承スキーマを作成することを検討しています: http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server

しかし、これを望む私の理由は、ほとんどの人が求めているものとは異なるようです. ほとんどの人は、異なる型に共通する列を共有するためにこのパターンを使用します。たとえば、FirstName列をEmployeeテーブルとCustomerテーブルの両方で複製するのではなく、共通のPersonテーブルに配置します。

しかし、私の場合、実際にはキー以外の共有列はありません。外部キーとして参照できるように、各子テーブルで共通キーを使用したいだけです。たとえば、各人に 1 つ以上の電話番号を持たせたい場合、共通のPersonテーブルの ID を参照するPhoneNumberテーブルを作成するだけで済みます。EmployeePhoneNumberテーブルとCustomerPhoneNumberテーブルを別々にしたくありません。

(キーを除いて) 共有列がない場合、クラス テーブルの継承は使用する正しいパターンですか? または、私が必要とするものをより良くする別のパターンがありますか?

[編集]

もう少しグーグルした後、ポリモーフィックアソシエーションは私が望むものの適切な用語であり、多くの場合、この方法で実装されているようです。誰かがこれについて何か言いたいことがある場合に備えて、この質問はもう少し開いたままにします.

私は、3 つの (主な) カテゴリの広告を掲載する、ペットに関する広告 Web サイトを設計しています。

私が直面している問題は、3 つの広告カテゴリすべてにいくつかの共通点がありますが、いくつかの相違点もあります。

たとえば、カテゴリ A、B、C には次のような共通点があります。

ただし、カテゴリ B の広告は「探している/販売中」に分類できませんが、B & C は分類できます。さらに、各カテゴリには独自のサブカテゴリがあります。たとえば、カテゴリ A には採用サブカテゴリがあり、販売サブカテゴリとカテゴリ C にはジョブ サブカテゴリとサービス サブカテゴリがあります。

また、カテゴリ C のみの給与などの珍しい属性もいくつかあります。

エンティティ属性値モデルとして取り組み始めましたが、いくつかの懸念があります。

1. これはパフォーマンスに影響しますか? ユーザーは、いくつかの固有の属性に基づいて検索できる必要があるためです。では、1 つの巨大なテーブルに対してクエリを実行しても、パフォーマンスに影響はありませんか?

2. 私の属性の 1 つは "Animal" (A & B に固有) です。最初は、Animal テーブルと Breed テーブルが必要でした (分類 DB モデルの独自のテーブルに Location があるのと同様です)。しかし、エンティティ属性モデルでこれを行う方法を想像できません。

これが私が思いついたデータベース設計です: http://i.imgur.com/jyV6Cjc.png

[アップデート]

クラス テーブルの継承を調べたところ、EAV モデルよりも適しているように思えたので、EER を次のように変更しました: http://i.imgur.com/JWPjt23.png

1. 求人広告とセール広告は「探している/提供している」として分類できますが、おそらくそれらの名前だけで、属性に大きな違いはありません (たとえば、価格と希望価格)。ここに別のレベルの継承を追加する必要があると思いますか、それとも面倒でしょうか?

2. 販売広告には、販売用のペット、養子縁組用のペット、養子縁組のリクエスト、ペットの購入のリクエストがあります。これらを 2 つの表に分けるべきだと思いますか。採用と販売？属性に大きな違いはなく、おそらく属性が 1 つ異なるだけです。

現在、講師と生徒の詳細を保存するプロジェクトに取り組んでいます。テーブルを 1 つ使用するか、テーブルをUser2 つ使用するかLecturer、およびStudent.

講師としてログインすると、プロジェクトのグループ管理ページとして特別な権限が与えられます。グループ ページが読み込まれると、学生には付与されません。Usertbl には、登録時に学生または講師を選択し、特別な講師コードを入力できるページがある列 がstatusあります。私はmySqlでPHPを使用しています。

まとめると、User学生用と講師用に1つのテーブルを使用するか、2つの別々Studentのテーブルを使用する必要がありLecturerます。

追加情報: 1 つのコースには多くの講師と受講生が含まれる場合がありますが、1 人の受講生には 1 つのコースが含まれ、講師には多数のコースが含まれます。

データベースの ORM として Entity Framework を使用しています。継承をモデル化するために、私のデータベースでは Table Per Type (別名 Class Table Inheritance) パターンを使用しています。Entity Framework は TPT 継承をサポートしています。ただし、速度は非常に遅いです。最も単純な linq クエリに対して非常に複雑な選択クエリを生成します。(この投稿を参照してください) データベースの継承の背景については、さまざまな種類の継承パターンに関する素敵な投稿があります。

別の方法として、私のデータベースでは、現在のオブジェクトの子の型を含む TPT パターンのバリエーションを使用しています。これは、この投稿の提案に従っています。結合する子テーブルがわかっているため、子のタイプを含めると、クエリがより簡単になります。

質問:次の TPT パターンを理解し、それに応じてより簡潔な選択クエリを実行するように Entity Framework に指示する方法はありますか? 次に、ORM からタイプ列を非表示にして、データベースにのみ表示することはできますか?

次の例を見てください。

親テーブル:

子テーブル:

一部のユーザーとエージェントを含むデータベースがあり、単純なメッセージ システムを追加したいと考えています。

したがって、次の単純なテーブルセットがあります。

私が持っていないのは、メッセージとメッセージを投稿した個人からの関係です。

ユーザーまたはエージェントである可能性があるため、少し行き詰まっているところがあります。これは、解決すべき受け入れられたパターンの一般的な問題であるに違いないと思いますが、そのような議論は見つかりませんでした。

いくつかのオプションがあることはわかっていますが、それらにはすべて短所があります。

オプション 1: メッセージが 2 つの異なるアカウントにリンクされる可能性があるのは好きではありません。

オプション 2: これにより、SELECT の 1 つの列ですべてのメッセージを取得することが難しくなります。

ユーザーとエージェントを 1 つのテーブルにまとめることができないことの 1 つです。それは石に設定されています。