Должен ли GUID использоваться как внешний ключ для многих таблиц

Question

Я разработал базу данных для использования GUID для UserID, но я добавил UserId в качестве внешнего ключа ко многим другим таблицам, и поскольку я планирую иметь очень большое количество входов базы данных Я должен проектировать это хорошо.

Я также использую таблицы членства ASP (не только членство в профилях, пользователи и роли).

Так что в настоящее время я использую GUID как ПК и как FK в каждой другой таблице, это, возможно, плохой дизайн? Что я думаю, может быть, лучше и является источником моего вопроса, следует ли добавить в таблицу пользователей UserId(int) в качестве первичного ключа и использовать это поле в качестве внешнего ключа для других таблиц и пользователя GUID UserId только для ссылки aspnet_membership?

aspnet_membership{UserID(uniqueIdentifier)} 
Users{ 
UserID_FK(uniqueIdentifier) // FK to aspnet_membership table 
UserID(int) // primary key in this table --> Should I add this 
... 
} 
In other tables user can create items in tables and I always must add UserId for example: 
TableA{TableA_PK(int)..., CreatedBy(uniqueIdentifier)} 
TableB{TableB_PK(int)..., CreatedBy(uniqueIdentifier)} 
TableC{TableC_PK(int)..., CreatedBy(uniqueIdentifier)} 
... 

Answer 1

В конечном счете, ответ заключается в том, что это действительно зависит.

Microsoft зафиксировала разницу в производительности каждого here. Хотя статья немного отличается от вашей ситуации, так как вам нужно использовать UNIQUEIDENTIFIER для ссылки на членство в asp, многие из пунктов обсуждения все еще применяются.

Если вам нужно создать собственную таблицу пользователей, было бы разумнее иметь собственный первичный ключ int и использовать GUID в качестве внешнего ключа. Он разделяет отдельные сущности. Что делать, если в какой-то момент в будущем вы хотели бы добавить к пользователю другое членство? Затем вам нужно будет обновить первичный ключ, который должен был бы каскадироваться в любые таблицы, ссылающиеся на него, и может быть довольно удачным. Если это только уникальный столбец в вашей таблице пользователей, это простое обновление.

Answer 2

Я бы выбрал ваш текущий дизайн.

Если вы беспокоитесь из-за внутреннего соединения в ваших запросах из-за сравнения строк вместо ints, то в настоящее время нет никакой разницы.

Answer 3

Все двоичные типы данных (uniqueidetifier - двоичные (16)) являются точными как внешние ключи. Но GUID может вызвать еще одну небольшую проблему как первичный ключ. По умолчанию первичный ключ кластер, но GUID генерируется случайным образом не последовательно, как IDENTITY, поэтому он часто разделяет страницы ввода-вывода, что приводит к снижению производительности.