0

各アイテムが複数の属性を持つことができるアイテムのデータベースを作成しようとしています。コンテナのテーブルもあります (コンテナはアイテムを保持できます)。各コンテナーには複数の必須属性があります。アイテムがコンテナに収まるには、アイテム属性がコンテナ属性の要件を満たしている必要があります。

注: 新しい属性はいつでも追加できます。

Example:
Item 1 Attributes
    Color: Red
    Material: Aluminum
    Length: 100
    Width: 200
    Rating: 4

Container 1 Required Attributes:
    Color=Red
    Material=Aluminum
    Length<105
    Width<300
    Rating=4

コンテナに収まるすべてのアイテムを検索したい。Container Required Attributes テーブルにコンパレータ用のフィールドがある場合、コンテナ 1 に必要なすべての属性を取得し、コンパレータ フィールドに基づいてクエリを動的に生成できます。私はデータベースの専門家ではありませんが、これは良い設計ではないようです。

もう 1 つのオプションは、複数の Container Required Attributes テーブルを用意することです。1 つは最大値、1 つは最小値、1 つは等しい値の数値、もう 1 つは等しい値の文字列などです。

Example:
Container 1 Maximum Attributes
Length: 105
Width: 300

Container 1 Minimum Attributes
<none>

Container 1 Equal Attributes (Float)
Rating: 4

Container 1 Equal Attributes (String)
Color: Red
Material: Aluminum

この場合、クエリを動的に生成する必要はありませんが、最終的には >= および <= のテーブルが必要になるため、これが最善の解決策とは思えません。

より良いデザインの提案はありますか?

4

2 に答える 2

1

あなたがこれを言うとき：

注：新しい属性はいつでも追加できます

それは非常に多くの結果をもたらします。当初開発されたSQLは、私が「動的データモデル」と呼ぶものをサポートすることを目的としていませんでした。データモデルでの新しいが欠落している属性の発見は、情報要件の変更、または現在の実装でのエラーまたは脱落の発見という2つのイベントのうちの1つだけによって発生しました。動的データモデリングは必ずしも悪いことではありませんが、従来のデータベース管理に伴う多くの規律を捨てることでそれを達成すると、対応する保証も同時に捨てることになります。

さらに一歩進んで、すべてのユーザーが新しい属性を追加したり、新しいデータを追加したりできると言うと、さらに多くの結果が生じます。2人のユーザーが同じ属性を発見し、異なる名前を付ける場合があります。これにより、「同義語の問題」が発生します。2人のユーザーが、2つの異なる属性を発見しても、両方に同じ名前を付ける場合があります。その結果、「同音異義語の問題」が発生します。これらの問題を未解決のままにしておくと、結果のデータを理解することはほぼ不可能になります。

既存のデータベースに新しい属性を追加することに関して重要な2つの違いを思い出させてください。SQLレベルでは、これがDDLとDMLの違いです。データレベルでは、メタデータとデータの違いです。あなたはこれのほとんどを知っているかもしれませんが、動的モデリングの観点から再考する価値があります。

従来のデータベースでは、既存のエンティティの新しく検出された属性またはエンティティ間の関係を実装する方法は、次のような構成になります。

alter table X add column Y ....

これはDDLです。DDLを実行する権利は通常、DBAに制限されており、データを提供したり、データを提供するためのインターフェイスとしてアプリケーションを使用したりするユーザーには付与されません。したがって、モデルはその意味で動的ではありません。また、DBAコミュニティ（複数のDBAがある場合）は、モデルを変更する前に相互に協議します。

既存のテーブルに列を追加するようなことをすると、2つのことが起こります。まず、実際のテーブルの構造を変更して、新しい列に対応します。次に、データディクショナリが更新され、テーブルの変更が反映されます。

data diciotnaryには、データベース自体のモデルを説明するデータであるメタデータが含まれています。ユーザーテーブルには、主題を説明するデータが含まれています。

一般に、SQLで動的モデリングを実装しようとすると、メタデータのコピー（列名など）がユーザーテーブルに格納されることになります。このユーザーデータと実際のデータ構造の間の相関関係、またはデータディクショナリへの反映を維持するのはあなたの責任になります。

あなたはこれを行うことができます。しかし、それは大変な作業です。そして、あなたはSQLがあなたが行くところに到達するための最良の方法ではないかもしれない旅に乗り出している。

于 2012-09-26T12:58:57.847 に答える
0

クエリ パラメーターは式のみであり、識別子 (列) や演算子ではないため、クエリを動的に生成しないようにする唯一の方法は、すべてのコンテナーに対して属性と比較の固定セットを用意し、値のみを格納することです。

Container 1 Required Attributes:
  Color: Red
  Material: Aliminum
  Max_Length: 105
  Max_Width: 300
  Rating: 4

コンテナごとに要件の数や種類が異なる場合、クエリはとにかく動的でなければなりません。その場合、複数の必須属性テーブルを使用しても、単一のテーブルよりも利点があるようには見えません。

WHERE属性が列に格納されている場合は、条件にプラグインする単一の文字列を格納することで、デザインをさらに動的にすることができますitems.color='Red' AND items.Length<105 .... これには、その文字列を解析せずに後で条件を変更できるようにする場合、条件を個別に保存する必要があるという欠点があります。

于 2012-09-26T07:12:05.960 に答える