1

サイド プロジェクト用のデータベース スキーマを設計しようとしてきましたが、満足できるものを作成できませんでした。データ アクセスに LINQ で ASP.Net を使用しています。

ユーザーは、それぞれ 2 つの数値プロパティと 1 つの参照プロパティ (アイテム名) を持つ最大 10 個の「アイテム」を指定できるようにします。

このエントリを 1 行に入れると、30 列以上 (最小) に簡単に等しくなります。たとえば、item_1_name (ref) item_1_weight item_1_volume item_2_name... など...

また、各プロパティの範囲は基本的に 1 から 400+ までであるため、これらの列を単純に参照テーブルに変換することはできません。

また、ユーザーが 1 つの項目のみをエントリに入れることを決定した場合、そのデータのオブジェクトを作成するメソッドは、LINQ と同様に静的になり、プロパティやその他のものが NULL であるかどうかを確認し、それに応じて動作する必要があることもわかりました。 . また、エントリで許可されるアイテムの数を増やしたいと思った場合、それを扱うのは頭の痛い問題です。

私が考えたもう 1 つのオプションは、単純に項目ごとに行を作成し、それをエントリ ID で結び付けることです。したがって、基本的に null エントリはありませんが、5 つの奇数列しかないため、テーブルは天文学的に深くなりますが、それほど広くはありません。

私の設計で見落としているものはありますか/これを行うためのはるかに優れた効率的な方法はありますか?

編集: 天文学的に成長すると言うとき、私はこの意味でそれを意味します: ユーザーはエントリを作成でき、各エントリにはアイテムのグループがある可能性が高いです。したがって、サイトに 1 日 1 エントリを作成するとします。3 つのアイテム グループがあり、アイテムの最大数 (10) があり、その唯一のエントリで 30 アイテムに相当します。そのレートで 1 週間毎日エントリを作成すると、その 1 人のユーザーに対して 210 行を作成できます。

4

3 に答える 3

2

あなたが言及した後者の設計をお勧めします。5 つの列を持つ 1 つの依存テーブルを作成します。

CREATE TABLE Items (
  user_id               INTEGER NOT NULL,
  item_id               INTEGER NOT NULL DEFAULT 1,
  numeric_property1     INTEGER,
  numeric_property2     INTEGER,
  referential_property  INTEGER,
  PRIMARY KEY (user_id, item_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
                        ON DELETE CASCADE,
  FOREIGN KEY (item_id) REFERENCES num_items(item_id),
  FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);

num_itemsユーザーを最大 10 項目に制限したい場合、1 から 10 までの数字を含む上の表を示します。

CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id) 
  VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);

この設計の利点はCOUNT()、特定のユーザーが持っているアイテムの数を簡単に計算できることMIN()、MAX()特定のプロパティに対して簡単に計算できること、参照プロパティに外部キーを適用できることなどです。

一部のデータベースには、複合主キー (item_idこの場合) の 2 番目の部分を自動インクリメントとして宣言する機能があるため、値を指定してentity_id省略するitem_idと、次の未使用の値が自動的に取得されます (ただし、削除してもギャップは埋められません)。 1）。あなたが使用しているデータベースのブランドを述べていないので、この機能を理解するのはあなたに任せます。

編集:トニー・アンドリュースが彼の答えで言っているように、行数は問題ではありません。使用する予定のデータベースのブランドは指定しませんが、MS Access のような特に貧弱な製品を選択しない限り、データベースに頼って数百万行を簡単に処理できます。インデックスを適切に選択し、それらのインデックスを使用するクエリを作成すれば、効率は問題になりません。

于 2008-11-04T16:43:12.290 に答える
0

単一アイテム テーブルを使用します。

userId、itemIndex、isReference、numericValue、referenceValue

このように、ユーザー 999 の item_3_name の値は次のように変換されます

999,3,真,ヌル,値

ユーザーごとのアイテムの最大数など、特定の制約を自分で適用する必要があります。

于 2008-11-04T16:38:45.993 に答える
0

適切なデータベース設計は、各ユーザー/アイテムを別々の行に格納することです。これにより、作業がはるかに簡単になり、任意の 10 アイテムの制限がなくなります。「天文学的に深く」成長するとは言いません。約10 x（ユーザー数）の行になります。

于 2008-11-04T16:43:19.417 に答える