0

最近、次のような状況に遭遇しました。

データベースを設計しており、データが 6 か月以内に数百万レコードに大幅に増加すると予測しています。そして、各行に一意の ID として Guid を持たせ、後でデータを OLAP/Archive データベースに移動できるようにする必要があります。Identity と Guid キーに関する多くの議論の後、一意の ID として Guid を思いつきました。ただし、主キーとしての Guid は常に悪い考えであるため、テーブルの主キーは Identity 列です。デザインは下のような感じ

ユーザー:

| Id (PK, Identity)                                                 |
| UserId (Guid, Unique-constraint, non-clustered index)             |  
| Name                                                              |
| Email                                                             |
| ...                                                               |

注:

| Id (PK, Identity)                                                 |
| NoteId (Guid, Unique-constraint, non-clustered index)             |
| UserId (Guid, Foreign Key to Users(UserId)                        |
| Title                                                             |
| Text                                                              |
| ...                                                               |

データをアーカイブに移動するとき、ID キーを気にする必要はもうありません。

このデザインに問題はありますか？パフォーマンスはどうですか？アドバイスをください、ありがとう。

4

1 に答える 1

1

GUID を主キーとして持っていなくても、それを結合に使用し、サーバーの作業を増やします。

Users.Id を FK ターゲットとして使用していない理由はありますか?

UserId (INT, Foreign Key to Users(Id)

上記の列にもインデックスを作成する必要があることに注意してください。そのため、テーブルに 2 つの GUID インデックスが残っていることに注意してください。 DB の NEWSEQUENTIALID()?

于 2013-05-21T08:50:55.040 に答える