Лучший тип данных первичного ключа для Linq to SQL

Я начинаю новый проект с SqlServer и Linq to Sql. Какой тип данных будет лучше для суррогатных ключей в таблицах: identity или uniqueidentifier?

Как я понял, identity автоматически создается при вставке, а uniqueidentifier должен быть сгенерирован в коде (GUID).

Существуют ли существенные различия в производительности? например identity значение должно быть прочитано после вставки, поэтому после вставки происходит дополнительная загрузка базы данных.

Edit:
Я нашел очень подробный ответ в другом вопросе: Таблицы без первичных ключей. Прочтите выбранный ответ.

Изменить 2:
Что касается ответов о суррогатных ключах: мне нравятся суррогатные ключи больше, чем естественные ключи. Это решение сделано, поэтому, пожалуйста, не предлагайте пересмотреть дизайн базы данных. Также, пожалуйста, не обсуждайте плюсы и минусы натуральных и суррогатных ключей.

ОТВЕТЫ

Ответ 1

Я согласен с комментарием здесь, что вы должны проектировать свою структуру db независимо от метода доступа к данным. Будь то LINQ2SQL или ADO.NET или NHibernate, вы получите тот же набор преимуществ/проблем, независимо от того, является ли ваш ПК идентификатором автоинкремента или GUID.

На самом деле я могу думать только об одной цели использовать GUID в пользу INT как PK - в высокораспределенном приложении с несколькими базами данных, где данные должны быть синхронизированы с главным сервером и т.д. Даже тогда вы могли бы использовать IDENTITY с разными приращениями, например IDENTITY (1,2) для одного сервера БД, IDENTITY (2, 2) со следующим и т.д. [Работает только с фиксированным числом серверов БД, конечно.]

Основная "проблема" с GUID заключается в том, что она занимает больше места (16 байт по сравнению с 4/8), а не только как ПК, но и как часть любого индекса в этой таблице, поскольку каждый индекс хранит значение PK неявно, Сравнение 16 байтов также будет медленнее (сколько? Вы должны его измерить, это зависит)

Кроме того, поскольку GUID является случайным, вы можете получить много разбиений на страницы при вставке строк (хотя я считаю, что есть новая функция в SQL Server 2005 или 2008 для генерации последовательных GUID) в таблицу. Это само по себе может быть довольно дорогостоящим в среде с большим количеством вставок.

Ответ 2

Либо одно прекрасно. Это зависит от вашего дизайна. UNIQUEIDENTIFIER будет работать, когда вам нужно создать идентификаторы на стороне клиента, что иногда может быть приятным, когда вы создаете список объектов, которые вам нужно будет добавлять/удалять/изменять на клиенте перед отправкой в ​​базу данных. Это также лучше, если вам нужно объединить данные, созданные в разных системах.

INTs меньше, поэтому они, вероятно, будут быстрее, и их гораздо проще использовать, когда вы отлаживаете что-то своими данными, потому что их легче обсуждать.

Короче говоря, здесь нет "лучшего" ответа. Это дизайнерское решение.

Ответ 3

Я не считаю целесообразным выбирать первичный ключ таблицы, основываясь на том, что вы используете LINQ-to-SQL. На мой взгляд, было бы гораздо лучше использовать первичный ключ по его намеченной цели - обеспечить целостность данных, однозначно идентифицируя определенную строку. Целочисленные или GUID PK не защищают вас от дублирования строк в вашей таблице (конечно же, за исключением автоматически созданных столбцов). Опять же, произошли большие дебаты, связанные с про и con автоматически сгенерированными ключами:)

Ответ 4

Я использую идентификатор и int или bigint в зависимости от ожидаемого размера таблицы. Я ожидаю, что LINQ выполнит один запрос, который объединяет как вставку, так и чтение ключа.

Ответ 5

uniqueidentifier также может быть вставлен автоматически, установив значение по умолчанию в базе данных на NEWID().

Ответ 6

ОК, я только что написал блог об этом. Я отдаю предпочтение ниже для других.

Основной смысл - это комментарии, сделанные в блоге ado.net, в котором утверждается, что Entity Framework - это единственное, что получает основное время разработки для Visual Studio 2010 и Dot Net 4.

Мы знаем это

Мой ответ - DUH. Мы все это знаем. Microsoft публично заявила в PDC 2007, что LINQ to SQL является краткосрочной версией для SQL Server, потому что в SQL Server не было другой истории LINQ. Он работает только с SQL Server. Вы не можете написать провайдера LINQ to SQL - для него нет модели. Это была одна технология, а не расширяемая.

Entity Framework = поставщик

Entity Framework - это единственный способ от Microsoft создать LINQ Provider. Структура Entity Framework оказалась довольно противоречивой, но я думаю, что отчасти это связано с тем, что LINQ to SQL имеет лучший опыт работы с программистами. Entity Framework поймает и превзойдет LINQ to SQL, потому что это инструмент ORM/Mapping будущего от Microsoft.

Я думаю, что Microsoft имеет огромные инвестиции в Entity Framework с сторонними поставщиками, такими как мы, IBM, Oracle и т.д. Если они хотят, чтобы сторонние разработчики и базы данных поддерживали LINQ, у них должна была быть модель для записи. Entity Framework - это ответ.

Я видел это в прошлом году, когда они вернули LINQ to SQL с VS 2008, а не EF. Они никогда не должны были выпускать закрытую реализацию чего-то с таким количеством перекрытий. Я знаю, что им нужна реляционная история базы данных, но я думаю, что они сказали не тот. В настоящее время есть много запутанных разработчиков, которые спрашивают нас о нашем поставщике LINQ to SQL. Существует не один, потому что вы не можете написать его.