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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Мы знали это

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

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

Entity Framework - это ЕДИНСТВЕННЫЙ путь от Microsoft по созданию поставщика LINQ. Платформа 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. Нет ни одного, потому что вы не можете его написать.

Answer 5

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

Answer 6

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