類似のオブジェクトごとに1つのテーブル？

Question

私はお店を描くためのアプリケーションを書いています。私のシステムには、ショップ、カート、ラック、ベーカリーというクラスがあります。

彼らは、この特性を有する：

ショップ：X、Y、名前、幅、高さ、タイプ、アドレス

カート場所：X、Y、名前、幅、長さ、タイプ、容量

を

ラック：X、Y、名前、幅、長さ、タイプ、高さは、

ベーカリーをbalance_limit：X、Y、名前、幅、長さ、タイプは、

をopen_hours今、私はrepreseしたいと思いますこれらのクラスをデータベースに登録してください。しかし、上のすべてのクラスは、次のようなものがあります。

X、Y、幅、高さ、名前、タイプ。そして、何それらが異なるようにすることです：

ショップ：アドレス

カート場所：容量

ラック：balance_limit

ベーカリー：open_hours

私が知っている将来的にすべてのこれらのタイプのオブジェクトの彼ら自身の新しい特性を持ち、それらが一度に持つであろう新しい特性を得ることになります。

私は店、カートの場所、ラックとパン屋と同じいくつかのプロパティを持つ上記のオブジェクトの新しいタイプがあることを知っています。

新しいプロパティと新しいオブジェクトを追加できるデータベース構造を作成したいと思います。同時に、すべてのクラスに追加される新しいプロパティを追加します。また、システムを明確に設計して、簡単にデータベースクエリを実行できるようにしたいと思います。

だから私の質問は次のとおりです。

私は、オブジェクトのすべてのタイプ（ショップ、カート場所、ラック、パン屋）のためのデータベーステーブルを確認する必要があり、それがより明確になりますか、私は1つのテーブルにすべて一緒にそれを組み合わせる必要がありますので、彼らは同様のプロパティのリストを持っているので？

1つのソリューションが他のソリューションよりも優れている理由を私に教えてください。私はここで実用的な助言を得ることを望むだけでなく、 "あなたはそれを行う必要があります、それは正しい方法、公理だから"。

Answer 1

これは簡単な質問ではありません。SQLデータベースは、クラス階層のモデリングには適していません。

あなたは良いORMが必要です。私は、テーブル内のクラス階層を置く何

、んはこれです：

まず、私は確信して、それが適切であることを確認してください：例えば、同じテーブル内のWeb CMSのためのノード、記事などを置くことので、理にかなっていますこれらはすべて同じものの変種です。

考えられるのは、SQLクエリを検索、インデックス作成、および作成するためのデータベース列を作成する必要がありますが、すべての情報をデータベース列に格納する必要はありません。残りはBLOB列の直列化オブジェクトに格納できます。

テーブルには、 があります。もちろん、この行がどのクラスを表す列であるかは、 です。すべてのクラスに共通するいくつかの「コア」列、基本的には基本クラスのフィールドです。 - いくつかのサブクラスでのみ使用されているが、検索に必要な他の列です。したがって、インデックスを付ける必要があります - オブジェクトの他のすべてのデータを含むBLOBです。

データベースにオブジェクトを格納すると、そのクラスに応じた関連する列が塗りつぶされ、残りのデータ（またはオブジェクト全体）がBLOBにスクロールされます。

大きな点は、検索または索引付けする必要がないメンバー値を追加して保存しただけで、データベース列に入れる必要がないため、変更を加えないことですデータベースはまったくありません。直列化されたBLOBに格納されます。唯一行うべきことは、このメンバーのデシリアライゼーションコードにデフォルト値を追加することです。そのため、このクラスのオブジェクトはデータベースに既に存在し、このメンバを持たないため、適切なデフォルト値が設定されます。

また、必要に応じてオブジェクト形式のバージョンを変更することもできますが、複雑になります。

しかし、この方式では、いくつかの欠点があります

制約が適用するのは困難である： - あなただけの列を持っている分野に制約を適用することができます。 - 一部の列は一部のクラスでのみ発生するため、データベースはクラス階層について少し知っている必要があります。

たとえば、別のテーブルにアドレスを入力し、関連するフィールド（郵便番号、国番号、通り番号など）を追加したいとします。このすべてをメインテーブルに置くと、余分な列が追加されます。また、ある時点で、異なるテーブルにある住所や住所を持つ顧客やその他の物を追加したいので、アドレスを別のテーブルに入れて参照してください。人や企業のための

同じこと、などが

今すぐお店にはアドレスを持っていますが、あなたのテーブルから行を参照する必要があり、そのデータベースのDDLで表現する必要がありますので、カートは、私は、想定されていません住所が "店舗"のタイプであるが、 "カート"のタイプではない場合。

少し毛むくじゃらするかもしれません。

また、たとえば10店舗と100000台のカートを持っている場合は、パフォーマンスの面でテーブルを分割するのが面白いかもしれないので、すばらしい小さなテーブルと1つの大きなテーブルが得られます。

---

は今、他のソリューションがあります。

たとえば、あなたは、基本クラス内のすべてのコードとベースメンバーを置くが、派生クラスで変更されたtableNameのクラス属性を作ることができます。このように、テーブル名を変更するだけで、すべてのコードが別のテーブルに適用されますが、それを書き換える必要はありません。

次に、クラスごとに1つのテーブルを取得します。

もちろん、クラス階層が複雑になる場合は、上記の方法を各テーブルに適用できます。

---

どのように2つの間で選択しますか？あなたがウェブCMSを作り、あなたがテーブルに格納する場合、基本的に、クラスのオブジェクトは次のようにノードから派生

： - 記事 - 伝説 とイメージ - ギャラリー - など

すべてのこれらのオブジェクトは基本的に同じもの。 これらはすべてTitle、TextContentフィールドがParentNodeなどに属します

TextContentで "foo"というキーワードを検索すると、すべてのオブジェクトが同じテーブルにある場合はずっと簡単になります。

ParentNodeのすべての子をWebページに表示する場合は、すべてが1つのテーブルにある場合はずっと簡単です。

この場合、最初の方法は本当に利点です。

あなたの場合、オブジェクトは似ていません。

個人的に私はそれらに同じ基本クラスを与えることさえできません。 ミックスインの名前を「ThingWithCoordinates」（多分もっと短いもの）にして、これをクラスに追加します。

今、おそらく、おそらくそうではないかもしれないが、おそらくベーカリーはショップに近い。

私は確かにいくつかのテーブルを使用します。各テーブルで、複数のクラスを保存する必要がある場合は、最初のメソッドを使用します。

最も重要なのは、クラス階層（したがってテーブル）は、RELEVANT（自動車ディーラーやベーカリーショップ）に基づいていなければならず、実際には何も共通しないオブジェクト間に存在する一般的な機能ショップ）。このために、共通コードを共有するためのミックスインがありますが、ベースクラスはありません。私が提案する何

Answer 2

はい、オブジェクトごとに1つのテーブルを使用する必要があります。 これらのテーブルをオブジェクトにマップすると、複数のテーブルを結合する必要がなくなり、より効率的になります。

また、各オブジェクトは、開発と複雑さの観点から分離されています。

Answer 3

共通アイテムのテーブルを「共有」すると、どのようなメリットがありますか？

もしそうでなければ、別のテーブルに貼り付けてください。（特に将来的にはさらに広がってしまいます）。

ORMを使用していないと思いますか？

Answer 4

：

1. は、データベースの問題にどのに関してせずに、正しくdomain modelを設計します。プロパティを共有するエンティティ（たとえば、の名前は）は、それらが何らかの形で関連していることを意味しません。彼らはうまくいくかもしれません...
2. このデザインをよく知られているObject-Relational Structural Patterns（Database Design参照）を選択してデータベース構造にマップします。
3. 適切なORMソリューションを使用して製品を開発します（できれば、基礎となるデータベース構造を後で変更できるようにすることが望ましい）。
4. パフォーマンスの問題が発生した場合は、(de)normalizingデータベースで問題を解決することを検討してください。

Answer 5

「汎化特化リレーショナルモデリング」でWebを検索してください。

このパターンが発生したときにSQLデータベースを設計する方法については、いくつかの良い記事があります。記事の中の最高のものは、標準的なルールを定めるのではなく、ガイダンスを提供するという基準に従っている。

Answer 6

共通性がshop_sizeと似ている場合は、別のテーブルを作成することをお勧めします。

これは、正規化によって他の情報を得ることができるため、同じ測定値のショップが多数あるため、幅と長さを簡単にドロップダウンすることができます。

この表に記載されているデータを見て、後で他の情報を取得することもできます。

主に、柔軟性、IMOを取得します。