問題タブ [class-table-inheritance]

この MySQL データベースを設計する最善の方法は何でしょうか?

私はcars、fuels、およびを持っていmotor oilsます。各車は、任意の数の を使用できfuelsますmotor oils。このデータベースを設計する最善の方法は何ですか?

したがって、1つまたは複数の、および 1 つcarまたは複数の を持つことができます。fuelsmotor oils

したがって、データベースに、、、およびテーブルcarsがfuels必要です。motor_oilsそれ以来fuels、motor_oils価格、日付_生産などのようないくつかの同様のプロパティがあります.言うことができますという別のテーブルを作成するのは賢明でしょうproductsか?

OOP 言語を使用する場合Product、エンティティがFuelあり、MotorOils拡張Productされ、このように でプロパティが定義されProductます。

Mysqlデータベースでこれをどのように設計しますか? MySQLには継承のようなものはありますか? リレーション データベースには継承がなく、MySQL でこれを模倣する方法があることは知っています。

Customer、Broker、Company などのエンティティがあります。これらには異なる属性があり、異なるテーブルにある必要があります。しかし、私たちの場合は連絡先情報 (エンティティ -> 連絡先は 1 対多の関係) のように、共通のものを持つことができます。それを行う最良の方法は何ですか。完璧な設計が存在しない場合、最も重要なことは可能な限り最小限のコードを記述することである場合はどうすればよいでしょうか。

ケース 1: すべてのエンティティに「共通」の auto-inc entityId があります (それらは主キーを共有するため、id=1 の Customer と id=1 の Company を持つことはできません)

ケース 2: 'contact' は、それが参照するエンティティに関する情報を格納します。(顧客、企業、ブローカーは主キーを共有しません)

ケース 3: エンティティごとに 1 つずつ、3 つの連絡先テーブル。

これらのテーブルを接続する方法は他にもありますが、頻繁に発生する問題です。特に解決策が気に入らないので、決定してください。

Nhibernate を使用していますが、複数の派生クラス (各クラスが異なるテーブルをマッピングする) を持つ基本クラスをフェッチするときに問題が発生します。リクエストを見ると、Nhibernate はすべての派生テーブルに参加しており、パフォーマンスに大きな影響を与えています...

これが私のクラスの単純化されたビジョンです:

ある人が動物のリストを持っていて、その名前が欲しいだけです。この例は完璧ではなく、より複雑です (銀行のプログラム) が、私の問題をよく反映しています。別の方法で実行できることはわかっていますが、それは遺産であるため、選択の余地はありません...

前もって感謝します。

class-table-inheritance (http://docs.doctrine-project.org/en/2.0.x/reference/inheritance-mapping.html#class-table-inheritance) を使用する Symfony2/Doctrine アプリに取り組んでいます。コンサルトで苦情を管理します。各コンサルトは多数の苦情 (OneToMany) を持つことができ、異なるタイプの苦情はそれぞれ異なる構造と外観を持っています。苦情はコレクションであり、JS で動的に追加されます。

この時点で、苦情を永続化する前にコントローラーで適切なタイプとして再キャストすることで、苦情を永続化し、コンサルトにリンクすることができます。これでいくつかの問題に遭遇しました。これをフォームイベント (http://symfony.com/doc/current/cookbook/form/dynamic_form_generation.html) またはその性質のものに移行して、プロセスを合理化することを計画しています。 .

ただし、この時点で発生している問題は、フォームビルダーが表示するコレクションのタイプを設定することを要求するため、FormView を使用してビューに既存の苦情を表示できないことです。各コンサルトに 1 つのタイプの苦情しかない場合は問題ありませんが、複数のタイプを持つことができ、フォーム ビルダーでタイプを設定すると、その 1 つのタイプに制限されます。

型が存在しない場合に FormView が文字列に変換されるのを停止するために使用できるアプローチはありますか、または苦情ごとに型を動的に検出して割り当てる方法はありますか ($complaint->getComplaintType() を使用)。多分）？

多くの列を共有する 3 つのテーブルがあるので、継承を使用してそれらをマッピングし、データ レイヤーをもう少し OOP や DRY などにすることを考えました。NHibernate マニュアル (クラス階層ごとのテーブル、サブクラスごとのテーブル、具体的なクラスごとのテーブル) に記載されている継承マッピングの 3 つの戦略のすべてで、スーパークラス (または共通インターフェイス) は、すべての派生サブクラスに共通の ID でマップされます。しかし、私のテーブルの主キー列はどれも同じと呼ばれていません。これをどのようにマッピングできますか？

図では:

TAXTYPE_1

• clcpnd -> 別の名前の Id 列
• clcnmb -> 共通だが異なる名前の列
• clcprc -> このテーブルに固有の特定の列

TAXTYPE_2

• rndind -> 別の名前の Id 列
• rndmb -> 共通だが異なる名前の列
• rndorc -> このテーブルに固有の特定の列

TAXTYPE_3

• dasfnd -> 別の名前の Id 列
• dastmb -> 共通だが異なる名前の列
• dascrc -> このテーブルに固有の特定の列

(はい、私の列はそのように命名されています。古いシステムです。変更できません。今すぐ私を殺してください)

編集:スキーマをより明確にしました。また、私の主張をもう少し明確にしたいと思います。3 つのテーブルは同じ型であり、共通のフィールドを実装するスーパータイプを抽象化し、詳細を各サブクラスに書き込めるようにしたいと考えています。したがって、TaxType クラスと、TaxType1、TaxType2、および TaxType3 サブクラスがあり、それぞれが「TaxType」です。また、これにより、単一の TaxType リポジトリなどでクエリを実行するため、他のレイヤーが使いやすくなります。質問がどれほどひどいものだったかを気づかせてくれた Jamie Ide に感謝します。

私は現在、2 つのテーブルを関連付けようとすると問題が発生する作業に取り組んでおり、そのうちの 1 つは一般化によるサブクラスです。

テーブル A には staffID の主キーがあり、これを一般化されたテーブル (テーブル B) の外部キーに関連付けたいと考えています。テーブル B のスーパー クラス (テーブル C) には staffID フィールドがあるため、一般化ではこれをテーブル C からテーブル B に運ぶ必要があります。

ただし、ダイアグラム ビューを使用して FK リレーションシップを設定する場合、ドロップ ダウン フィールドを見ると、テーブル B の属性のみが表示され、スーパー クラス (テーブル C) の属性は表示されないため、staffID は表示されません。

状況をより詳しく説明すると、スタッフには 2 つのタイプがあります。一方は汎化のすべてのテーブルでデータを作成できるため、staffID によってスーパー クラスに直接リンクされますが、もう一方のタイプのスタッフはいずれかのテーブルにのみデータを追加できます。サブクラス。

前もって感謝します

ここでは、次のモデルに対して複数クラスの継承モデルを設定する必要があります。基本的に、拡張可能な連絡先ディレクトリを構築しています。基本クラス Contact から、他のクラス、つまり次のようなものを派生させるつもりです。

各モデルは異なるテーブルに対応しています - 親クラスと子クラスの間に has_one belongs_to 関係があると思いますが、それを少し楽にする宝石があるかどうか疑問に思っていました. または、自分でそれをしなければならない場合、実際にどのようにそれを達成しますか.

たとえば、contact.name は実際には、個人の場合は person.first_name+' '+person.last_name、会社の場合は company.company_name です。これを正しく行うには、データベースと関連付けをどのように構成すればよいですか?

旅行管理アプリケーションを開発しています。問題のデザインは次のようなものです：

ツアーの各人は旅行者として指定されます。各旅行者はパスポートを持っています。現在、旅行者は、家族の長であるかどうかに応じて、メインメンバーまたはサブメンバーになることができます。MainMemberは、TourPackage、旅行中の家族の合計金額などを決定します。SubMemberは、旅行中はMainMemberに依存します。したがって、MainMemberが削除された場合、そのすべてのSubMemberも削除する必要があります。

つまり、旅行者はパスポートを持っています。（1対1の関係）トラベラーはMainMemberまたはSubMemberのいずれかです。（Traveler-MainMemberとTraveler-SubMemberの間で1対0 / 1）MainMemberには複数のSubMemberが含まれる場合があります。（1対多）サブメンバーには、メインメンバーが1つだけあります。（多対1）

私の現在のERDは次のようなものです。

ご覧のとおり、Traveler、MainMember、SubMemberの3つのテーブルは循環依存関係を形成しています。しかし、それが私のアプリケーションを傷つけるかどうかはわかりません。MainMemberであるTravelerを削除すると、1。Travelerのレコードが削除されます。2.関連するMainMemberレコードが削除されます。3.MainMemberに依存するSubMemberレコードが削除されます。4.サブメンバーのTravelerレコードが削除されます。

問題はないようですが、Traveler-MainMemberの削除では、常にTraveler-SubMemberのみが削除されます。それでも、私はこれについて悪い気持ちを持っています。

誰かが私をより良いデザインに導くことができますか？

アップデート -

返事を待っている間に、@Daveoの返事をもとに別のデザインを思いついた。基本的に、Travelerには自己参照外部キーが含まれています。これは、親を識別するためにSubMemberレコードによって使用されます。

これがそのためのERDです。

さて、@ Brankoが指摘したように、以前のデザインでは循環依存の問題がなかったので、どちらのデザインが優れているか知りたいですか？

また、Hibernateを介して実装するのに適した設計はどれですか？2番目のアプローチは、Hibernateを介して実装する際に複雑になる可能性があると思います。

また、好みの設計の実装パターン（Hibernateエンティティでの継承など）に関するいくつかの指針をいただければ幸いです。