2

さまざまな種類の情報を格納する会社用のデータベースを作成しています。カテゴリは、明るさ、コントラスト、色度などです。各カテゴリには、私の会社が保存を開始したい多数のデータ ポイントがあります。

通常、対応するデータを格納する各カテゴリのテーブルを作成します。（これが私がそれをすることを学んだ方法です）。ただし、これらのカテゴリには、各テーブルに必要なフィールドの数を変更する「サブデータ」がある場合があります。

私の質問は、データベースを構築する際に、データの不一致をどのように処理するのでしょうか? 追加データ用にテーブルを追加し続けるだけですか、それともまったく別のものですか?

4

3 に答える 3

2

リレーショナルデータベースモデルについては、曲げられないルールがいくつかあります（そして、良かったのはほんのわずかです）。そのうちの一つは、何を保存すればいいのかわからないと、保存するのに苦労するということです。たぶん、それを取得するのはさらに難しいでしょう。

とは言うものの、ビジネスルールの現実は、データベース設計の象牙の塔ほど明確ではないことがよくあります。最も重要なことは、スキーマを変更せずに新しいプロパティを導入する方法が必要な場合もあれば、必要な場合もあります。

これを実現するための2つの実行可能な方法は次のとおりです。

  1. 緩いスキーマまたは存在しないスキーマ（NoSQLおよびその仲間）に特化したデータストアを使用します。これを詳細に説明することはCS論文の主題であり、スタックオーバーフローの答えではありません。
  2. 私の推奨事項：別のプロパティテーブルを使用してください-これは次のようになります：

議論のために、あなたの製品は常に（一意の文字列）、name（整数）id、、、そして時々（整数）と（文字列）を持っていると仮定して、これらの表を検討してくださいbrightnesscontrastchromaticityfoobar

CREATE TABLE products (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  brightness INT,
  contrast INT,
  chromaticity INT,
  UNIQUE INDEX(name)
);

CREATE TABLE properties (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  proptype ENUM('null','int','string') NOT NULL default 'null',
  UNIQUE INDEX(name)
);

INSERT INTO properties VALUES
  (0,'foo','int'),
  (0,'bar','string');

CREATE TABLE product_properties (
  id INT PRIMARY KEY AUTO_INCREMENT,
  products_id INT NOT NULL,
  properties_id INT NOT NULL,
  intvalue INT NOT NULL,
  stringvalue VARCHAR(250) NOT NULL,
  UNIQUE INDEX(products_id,properties_id)
);

これで、「標準」プロパティは通常どおりテーブルに表示され、「オプション」プロパティは、またはの値で製品IDとプロパティIDを参照productsするの行に格納されます。product_propertiesintvaluestringvalue

それらを含む製品を選択すると、次のfooようになります

SELECT 
  products.*,
  product_properties.intvalue AS foo
FROM products
  LEFT JOIN product_properties 
    ON products.id=product_properties.product_id 
    AND product_properties.property_id=1

あるいは

SELECT 
  products.*,
  product_properties.intvalue AS foo
FROM products
  LEFT JOIN product_properties 
    ON products.id=product_properties.product_id 
  LEFT JOIN properties 
    ON product_properties.property_id=properties.id
WHERE properties.name='foo' OR properties.name IS NULL

これにはパフォーマンスのペナルティが発生することを理解してください。実際、パフォーマンスと柔軟性をトレードオフします。別のプロパティを追加INSERTすることは、行を追加するだけでpropertiesあり、スキーマは同じままです。

于 2012-06-26T21:55:34.270 に答える
0

mysqlにバインドされていない場合、他のデータベースには、これらのニッチなケースの特定を解決するためのテーブル継承または配列があります。Postgresqlは、mysqlと同じくらい簡単かつ自由に使用できる非常に優れたデータベースです。

mysqlを使用すると、次のことができます。

  1. テーブルを変更し、列を追加して、不要なサブカテゴリデータでNULLを許可します。このようにして、列に制約を設定できるため、整合性をチェックできます。このようにサブカテゴリ列が本当にたくさんある場合を除いて、これをお勧めします。そうでない場合は、オプション3をお勧めします。

  2. サブカテゴリデータを、category_id、category_row_id、subcategory識別子（=サブカテゴリのタイプ）と値の列を持つ別のテーブルに動的に格納します。これにより、category_id（テーブルを決定）とcategory_row_id（テーブルを決定）を介してデータをリンクすることでデータを取得できます。元のカテゴリテーブル行のPKへのリンク）。悪い点：外部キーや制約を適切に使用して整合性を強制することはできません。整合性チェックと参照チェックの負担をクライアントだけに押し付ける制御を維持するために、ヘアリー挿入/更新トリガーを作成する必要があります。 。（この場合、NoSQLルートを使用する方が適切です）要するに、これはお勧めしません。

  3. カテゴリテーブルごとに個別のサブカテゴリテーブルを作成できます。列は値列+オプションのサブカテゴリ識別子を介して固定または可変にすることができます。外部キーは引き続き使用できます。整合性を維持するのに最適なのは、自由に使える制約。通常のサブカテゴリテーブルが乱雑になる可能性のあるサブカテゴリ列が多数ある場合は、固定列でこれを使用することをお勧めします。前のオプションと同様に、使い捨てデータ以外は動的にすることはお勧めしません。

または、サブカテゴリが非常に可変で不安定な場合：mongodbなどのドキュメントデータベースでNoSQLを使用します。すべての通常のデータを適切なRDBMSに保持し、ストアサイドデータだけをドキュメントデータベースに保持できることに注意してください。ただし、これはおそらくお勧めできません。

サブカテゴリデータが既知の固定状態にあり、変更される傾向がない場合は、特定のカテゴリテーブルに列を追加するだけです。適切なDBMSの主な機能は、チェックと制約を介してデータの整合性を保護することであることに注意してください。これを廃止することは、決して良い考えではありません。

于 2012-06-26T22:01:46.047 に答える
0

MySQL に限定されていない場合は、Microsoft SQL サーバーとスパース列の使用を検討でき ます。これにより、スキーマを拡張して、特定の行に関係のない列のストレージ ペナルティを被ることなく、必要な数の列を含めることができます。

于 2014-12-10T21:56:48.443 に答える