6

オブジェクト指向プログラミングのスーパークラスのように機能する DB (Postgres ベース) にテーブルがあります。テーブルに追加する列を決定する「タイプ」列があります (サブクラス プロパティ)。しかし、可能なすべての列 (可能なすべての型のすべてのプロパティ) をテーブルに含めたくありません。

そこで、「キー」列と「値」列 (つまり、「ファイル名」 = 「/ファイル」、または「値」 = 「5」) を含むテーブルを作成することにしました。スーパークラス テーブルで。また、使用可能な「キー」値を含む関連テーブルを 1 つ作成しました。

しかし、このようなアーキテクチャには問題があります。何でも含めることができるように、「値」列はデフォルトで文字列データ型でなければなりません。しかし、文字列との間の変換は良い決断ではないと思います。この制限を回避する最善の方法は何ですか?

4

8 に答える 8

10

実験している設計はEntity-Attribute-Valueのバリエーションであり、多くの問題と非効率性が伴います。最後の手段を除いて、これはあなたがしていることの良い解決策ではありません。

より良い解決策となる可能性があるのは、fallen888 が説明していることです。サブタイプごとに「サブタイプ」テーブルを作成します。これは、あなたが持っているもののように聞こえる有限数のサブタイプを持っている場合は問題ありません。次に、サブタイプ固有の属性にデータ型を指定できます。また、NOT NULL必要に応じて制約も指定できますが、これは EAV 設計を使用する場合は不可能です。

サブタイプ テーブル設計の残りの弱点の 1 つは、スーパークラス テーブルのメイン行がそうすべきだと言っているからといって、サブタイプ テーブルに行が存在することを強制できないことです。しかし、これは EAV 設計によって導入されたものよりも穏やかな弱点です。

編集:任意のエンティティへのコメントに関する追加情報については、はい、これはかなり一般的なパターンです。この状況で多くの人が使用する手法である「ポリモーフィック アソシエーション」と呼ばれる壊れたソリューションに注意してください。

于 2008-12-08T23:45:57.470 に答える
2

代わりにこれはどうですか...各サブタイプは独自のDBテーブルを取得します。また、ベース/スーパーテーブルには、サブタイプDBテーブルの名前を保持するvarchar列があります。次に、このようなものを持つことができます...

Entity
------
ID
Name
Type
SubTypeName   (value of this column will be 'Dog')


Dog
---
VetName
VetNumber
etc

（サブ）テーブル名をベーステーブルのvarchar値にしたくない場合は、主キーがベーステーブルにあるSubTypeテーブルを作成することもできます。

于 2008-12-08T22:45:09.730 に答える
0

（構造を保持しながら）唯一の回避策は、個別のテーブルを用意することです。

create table IntProps(...);
create table StringProps(...);
create table CurrencyProps(...);

しかし、これは良い考えではないと思います...

于 2008-12-08T22:44:13.273 に答える
0

一般的なアプローチの1つは、Key-Valueテーブルに、StringValue、DecimalValueなどのデータ型ごとに1つずつ、複数の列を含めることです。

変更する必要のないデータベーススキーマのクエリ可能性とパフォーマンスを交換していることを知っておいてください。ORMマッピングまたはオブジェクトデータベースを検討することもできます。

于 2008-12-08T22:45:07.267 に答える
0

タイプごとのキー/値テーブルを持つことができます。使用可能なテーブルは、正しく型付けされたキー/値テーブルを指すために、特定のキー/タイプのペアの可用性をエンコードする必要があります。

ただし、これは、行ベースのリレーショナルデータベースでは非常に非効率的なアーキテクチャのようです。

おそらく、列指向のリレーショナルデータベースを確認する必要がありますか？

于 2008-12-08T22:47:53.983 に答える
0

答えてくれてありがとう。必要なものをもう少し具体的に説明します。ブログ + フォーラムの Web サイトをプログラミングする必要があり、 WordPress の DB 構造を見てきました。

ブログ エントリやビデオ ファイルの添付など、あらゆる種類の「オブジェクト」にコメントを配置できる機能が強く求められています。上記の DB 構造は、スケーリングが非常に簡単で、すべてのニーズを満たすことが、選択の理由でした。

しかし、それを変更するのに遅くはありません。これは初期のエンジニアリングの段階にあるためです。また、私たちのモデルは、完全にツリー階層ベースの DB のような匂いがします。今のところ、 Bill Karwin と fall888 の回答を受け入れますが、完全に間違った方向に進んでいる可能性がありますか?

于 2008-12-09T11:07:44.177 に答える