Linq2Sql: Могу ли я создать сущности со связями внешнего ключа без первичного ключа в обеих таблицах?

Question

В моей базе данных есть 2 таблицы, для которых я пытаюсь создать сущности Linq2Sql. Для них есть нечто большее, но по сути это то, к чему они сводятся:

Rooms          UserActivity
--------       --------
RoomID         ActivityID 
               RoomID (foreign key on Rooms.RoomID)

Таблица UserActivity - это просто журнал действий, которые пользователь выполняет с таблицей Rooms.

Поскольку таблица UserActivity используется только для регистрации предпринятых действий, не имело большого смысла (по крайней мере, для меня) изначально создать первичный ключ для таблицы, пока преобразователь Linq2Sql не отказался сделать UserActivity часть сущности Room в моих сущностях Linq. Когда я настраивал сущности в конструкторе Visual Studio, я получил следующие 2 предупреждения:

• Warning 1 DBML1062: The Type attribute 'UserActivity' of the Association element 'Room_UserActivity' of the Type element 'Room' does not have a primary key. No code will be generated for the association.
• Warning 2 DBML1011: The Type element 'UserActivity' contains the Association element 'Room_UserActivity' but does not have a primary key. No code will be generated for the association.

Эти предупреждения привели меня к созданию столбца ActivityID в моей таблице, как показано выше.

Что я хотел бы знать, так это то, что есть ли способ разрешить Linq2Sql создавать отношения между моими сущностями, не имея первичного ключа в обеих таблицах. Если у меня нет первичного ключа в таблице UserActivity, сущности все еще могут быть созданы, но отношения не генерируются.

Возможно ли это сделать или я должен стараться, чтобы в моих таблицах всегда был первичный ключ, что является общей хорошей практикой?

Answer 1

Любая таблица, в которой хранятся реальные данные в вашем приложении, всегда должна иметь первичный ключ - в большинстве случаев в средах SQL Server INT IDENTITY (1,1) будет вполне приемлемым. Вам не нужно следить за ними, не нужно вести бухгалтерию и т. Д. Это не будет стоить вам много, это легко сделать - я не вижу причин, почему бы не иметь первичный ключ, даже на вашей таблице UserActivity .

ALTER TABLE UserActivity
  ADD UserActivityID INT IDENTITY(1,1) 
  CONSTRAINT PK_UserActivity PRIMARY KEY

и все готово!

Единственный раз, когда я бы сказал, что первичный ключ не требуется, это такие вещи, как временные таблицы при массовом импорте огромных объемов данных или другие временные сценарии.

Марк

Answer 2

Вам нужен первичный ключ для создания отношений. Рекомендуется всегда создавать таблицы с первичными ключами, даже если вы добавляете суррогат (идентификатор с автоматическим приращением).