Различие между созданием Гуида вводит C# по сравнению с DB

Я позволяю пустому Гуиду быть индикатором, что этот объект, хотя создано, еще не был вставлен в (или получен от), база данных.

GUID ужасны для производительности

Я оставил бы его в базе данных особенно теперь, когда SQL Server имеет NEWSEQUENTIALID (), который не вызывает расщепления страницы на вставках больше, потому что значения случайны, каждый созданный NEWSEQUENTIALID будет больше, чем предыдущий... только caviat - то, что это может только использоваться в качестве значения по умолчанию

Путем выполнения его в C# Вы могли бы рискнуть повторно присваивать GUID и сохранять его назад к базе данных. При наличии базы данных быть ответственными за него, Вам гарантируют, тот этот PK не изменится, то есть, при установке надлежащих ограничений. Однако Вы могли установить подобные ограничения в своем коде C#, которые предотвращают изменение уникального идентификатора, после того как это было присвоено, но необходимо будет сделать то же во всех приложениях... По-моему, наличие его в C# походит, больше обслуживания, чем база данных, так как базы данных уже создали в методах для предотвращения изменяющихся первичных ключей.

Поскольку SQLMenace отмеченные, стандартные GUID негативно влияет на индексацию и подкачку страниц. В C# можно генерировать последовательные GUID как NEWSEQUENTIALID () использующий немного забавы P/Invoke.

[DllImport("rpcrt4.dll", SetLastError = true)]
static extern int UuidCreateSequential(out Guid guid);

Таким образом, можно, по крайней мере, продолжать использовать GUID, но получить больше гибкости с тем, как и где они сгенерированы.

Хорошо, время для вмешиваний. Я сказал бы, что сгенерированный GUID, клиентские для сохранения к базе данных, являются лучшим способом сделать вещи - если Вы, оказывается, используете GUID в качестве своего PKs, который я только рекомендую в одном сценарии: разъединенная среда.

Когда Вы используете разъединенную модель для своего распространения данных (т.е. приложения для КПК/сотового телефона, приложения для ноутбука, предназначенные для ограниченных сценариев возможности соединения, и т.д.), GUID, поскольку PKs, сгенерированные клиентский, являются лучшим способом сделать это.

Для любого сценария Вы, вероятно, более обеспечены с автоинкрементными идентификационными данными PKs.

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

Интересный вопрос.

Традиционно я также использовал DB присвоенный гуид, но недавно я работал над приложением Windows Mobile, и база данных SQL CE не допускает newguid, таким образом, я должен был сделать это в коде.

Я использую репликацию SQL для получения данных с мобильных устройств на сервер. За прошлые 6 месяцев у меня было 40 SQL, клиенты CE синхронизируют назад более чем 100 000 записей на сервер SQL 2005 без одного пропущенного или дублированного гуида.

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

Я не сделал никакой производительности, проверяющей так производительность в стороне, я не вижу причины не реализовать гуид, обрабатывающий, как Вы предполагаете.

Если когда-нибудь необходимо делать вставку за пределами GUI (думайте импорт от другого поставщика или данные компании, которую Вы купили и должны объединить со своими данными), то GUID не был бы автоматически присвоен. Это не непреодолимая проблема, но это - что-то для рассмотрения, тем не менее.

Кроме кластеризирующейся проблемы (который, кажется, не проблема, если Вы настраиваете свои индексы правильно),

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

Самый большой недостаток, по моему скромному мнению, является размером - GUID составляет 16 байтов, INT равняется 4. PK не только хранится в дереве первичного ключа, но также и НА КАЖДОЙ записи некластерного индекса.

С несколькими тысячами записей, которые не могли бы иметь большое значение - но если у Вас есть таблица с миллионами или миллиардами записей и несколькими некластеризованными индексами, с помощью 16-байтового GUID по сравнению с 4-байтовым INT, поскольку PK мог бы иметь Огромное значение в необходимом пространстве - на диске и в RAM.

Marc