Почему не всегда используют GUID вместо Целочисленных идентификаторов?

Question

Почему не всегда используют GUID вместо Целочисленных идентификаторов?

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

для использования Исключений или не для подтверждения правильности данных. Я думаю, что нормально использовать исключение в процессе (хотя все еще предпочтительный), но за пределами процесса, назовите метод для проверки бизнес-объекта (например, прежде, чем сохранить) и иметь метод возвращают успех операции наряду с любой проверкой ошибки . Ошибки не являются' исключительными.

Microsoft выдает исключения от бизнес-объектов, когда проверка перестала работать. По крайней мере, это - то, как Блок приложений Проверки Библиотеки Предприятия работает.

using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;
public class Customer
{
  [StringLengthValidator(0, 20)]
  public string CustomerName;

  public Customer(string customerName)
  {
    this.CustomerName = customerName;
  }
}

7

sql sql-server database-design

задан gbn 9 September 2009 в 04:56

8 ответов

GUID великолепны с точки зрения программиста - они гарантированно (почти) уникальны, так почему бы не использовать их везде, верно?

Если вы посмотрите на это с точки зрения администратора баз данных и с точки зрения базы данных, по крайней мере для SQL Server, есть несколько вещей, которые следует учитывать:

GUID в качестве первичного ключа (который отвечает за однозначную идентификацию одной строки в вашей таблице) могут быть приемлемыми - в конце концов, они ' уникальны, не так ли?
однако в SQL Server также есть концепция ключа кластеризации, который физически упорядочивает данные в вашей таблице; если вы не знаете об этом и ничего не делаете явно, ваш первичный ключ становится вашим ключом кластеризации.

Кимберли Трипп, всемирно известный эксперт по индексации и производительности SQL Server, написала в блоге множество сообщений о том, почему GUID в качестве ключа кластеризации - действительно плохая идея - посмотрите ее блог об индексах .

В частности, ее лучшие практики для ключа кластеризации:

узкий
статический
уникальный
постоянно увеличивающийся

GUID, как правило, статичны и уникальны, но они не узкие ( 16 байт против 4 байтов для INT) и никогда не увеличивается. Из-за своей природы они уникальны и (псевдо) случайны.

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

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

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

Marc

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

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

Marc

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

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

Marc

11