0

今ではかなり明白なパターンに気づきました。これについてあなたの意見を聞く必要があります。

リレーショナル モデルで、テーブル 1 からテーブル 2 への 1 対多の関係があるとします。たとえば、テーブル 1 はユーザー テーブルであり、テーブル 2 はすべてのユーザー ログインを記録するログイン テーブルである可能性があります。1 人のユーザーが複数回ログインできます。ユーザーを指定すると、そのユーザーによるすべてのログインを見つけることができます。

頭に浮かぶ最初のアイデアは、ログインをログイン テーブルにのみ格納することです。これがデザインワンです。

しかし、いくつかのユースケースで、ユーザーの特定のログイン (最後のログインなど) に関心がある場合は、最後のログイン時刻をユーザー テーブル自体にキャッシュするのが「一般的に良い考え」です。そうですか？

設計 2 は、結合を実行してから以前のログイン以外をすべて破棄することで、常に最後のログイン時刻を見つけることができるため、明らかに冗長です。

1 人のユーザーの場合、どちらでも問題ありません。しかし、すべてのユーザーの最終ログイン時刻を SQL クエリで調べたい場合、デザイン 1 では結合とサブクエリを使用して、不要な結果を除外します。

しかし、私たちのユースケースを考えると、最後にログインした時刻を user テーブル自体に保存することをお勧めします。これにより、結合を回避できます。そうですか？

これは、スキーマの設計時に見られる一般的なパターンですか?

4

1 に答える 1

0

TABLE と RELATION の概念を混同しています。よくある間違いです。概念モデル (ユーザーとログイン) には 2 つの RELATION がありますが、実際には物理モデルに 2 つ以上のテーブルが含まれます。クラスター化されていないインデックスは、複数の RELATION の結合を高速化するための追加のテーブルに過ぎないためです。

ユーザーとの FK 関係をサポートするために INDEX (UserID、LoginTime) がログインに存在すると、ユーザーの最新のログインを検索するクエリは、非クラスター化インデックスによってカバーされます。このデフォルト モデルで既知の測定可能な深刻なパフォーマンスの問題が特定された場合にのみ、非正規化を検討します。これは、(すべての非正規化と同様に) 非正規化されたテーブルでのすべての読み取りおよび書き込み操作のパフォーマンス ヒットが発生するためです。

于 2013-03-10T18:54:49.757 に答える