0

データベース スキーマの設計について教えてください。

すなわち。私の問題は、1 つのアクティビティに 1..* date_held があることです。

例えば。活動名は

「映画を見る」の date_held は 9 月 1 日です

"shopping" の date_held は 9 月 2 日、9 月 5 日、9 月 6 日です。

方法1

私の現在のデータベース設計は

---------------------------
Activity Table
---------------------------
id|name|date_held

1|see moive|20120901

2|shopping|20120902

3|shopping|20120905

4|shopping|20120906

買い物履歴が3回重複していることが分かります。よくないように思います。


方法2

だから私は3つのテーブルに分けます

---------------------------
Activity Table
---------------------------



id|name

1|see moive

2|shopping


---------------------------
Date Table
---------------------------
id|date

1|Sep 1

2|Sep 2

3|Sep 5

4|Sep 6



---------------------------
Activity_Date Table
---------------------------
activity_id|date_id

1|1

2|2

2|3

2|4

しかし、方法2は非常に混乱していると思います。1 アクティビティマッチ 1..* date_held?

ありがとう！！



こんにちは、ブランコ・ディミトリイェビッチ

数時間考えた後、別の方法を発見しました。つまり、redis json形式を使用します

{

"名前":"ショッピング",

"日にち"：[

「9月1日」

]

}、

{

"name": "映画を見る",

"日にち"：[

「9月2日」「9月5日」「9月6日」

]

}

とても簡単に思えます〜:D

しかし、私はあなたの提案を考えさせてください..

4

1 に答える 1

0

買い物履歴が3回重複していることが分かります。

name フィールドの値は、単独で取得すると、異なる行で繰り返されます。レコード全体 (行) は繰り返されません。

論理的には、同じ活動が複数の日付で繰り返される場合、その活動1を識別する同じデータをこれらの日付ごとに繰り返す必要があります。魔法はなく、関連するすべての組み合わせをデータベースに登録する必要があります。幸いなことに、データベースは大量のデータを処理するのに適しています。

ここには2つの問題があると思います：

  1. 代理キーが必要idですか? 同じ日付に同じアクティビティが決して存在しない場合{name, date_held}、 などの別の「代理」キーを追加するかどうかに関係なく、 は「自然」キーですid。したがって、実際にサロゲート PK が必要でない限り、自然キーをプライマリのままにしておくことができます。1 日に複数のアクティビティが発生する可能性がある場合は、 に置き換えることdate_heldを検討してdatetime_heldください。

  2. 3 番目のテーブルが必要ですか。名前だけでなく、より多くの情報を各アクティビティに関連付けたい場合、またはアクティビティが保持されなくても存在できるようにしたい場合は、とにかく論理レベルでそれが必要です。しかし、そうしなくても、純粋に物理的なレベルでは、3 番目のテーブルでサロゲート PK を使用すると、文字列を繰り返す必要がなくなり、代わりに (よりスリムな) 整数を繰り返すことができます。これにより、スペース (およびキャッシュのパフォーマンス) を節約できる可能性がありますが、より多くの JOIN が必要になる可能性もあります。おわかりのように、それはバランスの問題であり、測定値は適切なものを選択するための非常に貴重なツールになる可能性があります.

1アクティビティ名または ID です。

于 2012-09-05T11:13:04.373 に答える