Какой тип данных рекомендуется для столбцов идентификаторов? - PullRequest
7 голосов
/ 31 мая 2009

Я понимаю, что этот вопрос, скорее всего, задавался раньше, но я немного искал среди вопросов по StackOverflow, и я действительно не нашел ответа на свой, так что здесь. Если вы найдете дубликат, пожалуйста, ссылку на него.

По некоторым причинам я предпочитаю использовать Guid s (uniqueidentifier в MsSql) для моих полей первичного ключа, но я действительно не знаю, почему это было бы лучше. Во многих уроках, которые я проходил в последнее время, используется автоматически увеличенный int. Я могу видеть плюсы и минусы с обоими:

  • A Guid всегда имеет один и тот же размер и длину, и нет причин беспокоиться о том, что их не хватит, в то время как существует ограничение на количество записей, которое вы могли бы иметь, прежде чем у вас закончатся числа вписывается в int.
  • int - это (по крайней мере, в C #) обнуляемый тип, который открывается на пару ярлыков при запросе данных.
  • И int легче читать.
  • Бьюсь об заклад, вы могли бы придумать здесь, по крайней мере, еще пару вещей.

Итак, как говорится в заголовке: Какой рекомендуемый тип данных для столбцов идентификаторов (первичного ключа) в базе данных?

РЕДАКТИРОВАТЬ: После получения нескольких коротких ответов, я также должен добавить этот дополнительный вопрос. Без него ваш ответ не будет ни убедительным, ни обучающим ...;) Почему вы так думаете, и каковы минусы другого варианта, который заставляет вас не выбирать это вместо этого?

Ответы [ 9 ]

8 голосов
/ 31 мая 2009

Любой целочисленный тип достаточного размера для хранения ожидаемых диапазонов данных. Обычно 32-битные целочисленные значения рассматриваются как слишком маленькие (правильно или неправильно) для таблиц с большим количеством строк или изменений. 64-битный int - это достаточно. Многие базы данных не будут иметь или не будут использовать этот целочисленный тип, но будут использовать тип NUMBER с указанным масштабом и точностью. 10-15 цифр - довольно распространенный размер.

Причина выбора целочисленных типов двойная:

  1. Размер; и
  2. Speed.

Размер целого числа:

  • 32 бита: 4 байта;
  • 64 бит: 8 байтов;
  • Двоичный код в двоичном коде: две цифры на байт плюс целое число байтов для знака, масштаба и / или точности.

Сравните это с GUID , который равен 128 битам или обычной строке, которая составляет не менее одного байта на символ (больше в определенных кодировках символов) плюс издержки, которые могут быть всего одним байтом (завершающий ноль) или может быть намного больше в некоторых случаях.

Сортировка целых чисел тривиальна, и, предполагая, что они уникальны и диапазон достаточно мал, фактически можно выполнить за O (n) время по сравнению с, в лучшем случае, O (n log n).

также, что не менее важно, большинство баз данных могут генерировать уникальные идентификаторы посредством автоинкрементных столбцов и / или последовательностей. Гарантия уникальности в приложении на самом деле довольно сложна и приводит к раздутым ключам.

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

6 голосов
/ 31 мая 2009

Популярные базы данных позволяют увеличивать поля автоинкремента в течение многих лет, так что это гораздо меньше проблем.

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

Плюсы для GUID:

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

Плюсы для автоинкремента:

  • Человек понятен.
  • Последовательное назначение означает, что вы можете использовать кластерный индекс и влиять на производительность.
  • Подходит для разделения данных.
5 голосов
/ 31 мая 2009

Большим недостатком использования ключей GUID является то, что трудно выполнять «специальные» запросы вручную. Иногда очень полезно, что вы можете сделать это:

SELECT * FROM Пользователь, где UserID = 452245

С клавишами GUID это может стать очень раздражающим.

Я бы порекомендовал 64-битные целые числа

2 голосов
/ 31 мая 2009

Скажите, какие критерии вы считаете важными.

Что требуется должно быть уникальным в таблице.

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

Номер автоинкремента хорош; он маленький и обязательно будет уникальным в таблице. С другой стороны, это не дает вам защиты от дублирования; легко создать две записи, идентичные, кроме магического числа.

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

1 голос
/ 31 мая 2009

Если вы используете long, вы можете создать более 1000 в секунду и не использовать первичные ключи в течение 29 миллионов лет.

Другие уже упоминали о некоторых преимуществах использования целочисленного типа вместо UUID / GUID. Одним из больших преимуществ является скорость и компактность индексов.

Приложение, в котором я недавно участвовал, где я проектировал базу данных, мне были нужны UUID, но я не хотел отказываться от преимуществ использования long для первичных ключей, поэтому у меня была таблица "allIds", которая отображала все первичные введите в систему UUID. Все мои первичные ключи были сгенерированы из одной последовательности, поэтому они были уникальны для всех таблиц.

0 голосов
/ 06 мая 2019

Мне никогда не нравились целые числа и увеличенные идентификаторы. Это создает проблему, когда вы хотите скопировать данные в разные таблицы (две таблицы с одинаковым идентификатором) или в разные базы данных. Guid является большим представителем строк, и он также сталкивается с проблемой, когда вы включаете идентификаторы в URL-адреса веб-приложений. Поэтому я решил использовать версию Guid с короткой строкой, которая в БД похожа на varchar (16). См. Код ниже (метод WebHash ()):

public static class IdentifyGenerator
{
    private static object objLock = new object();

    private static char[] sybmols = {
                         '0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
                         'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j',
                         'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't',
                         'u', 'v', 'w', 'x', 'y', 'z',
                     };

    /// <summary>
    /// Creates a new Unique Identity HashCode (length 16 chars)
    /// </summary>
    /// <returns></returns>
    public static string WebHash(Guid fromGuid = default(Guid))
    {
        lock (objLock)
            return RandomString(16, (fromGuid != default(Guid) ? fromGuid.ToByteArray() : null));
    }

    public static string RandomString(int length, byte[] customBytes = null)
    {
        Stack<byte> bytes = customBytes != null ? new Stack<byte>(customBytes) : new Stack<byte>();
        string output = string.Empty;

        for (int i = 0; i < length; i++)
        {
            if (bytes.Count == 0)
                bytes = new Stack<byte>(Guid.NewGuid().ToByteArray());
            byte pop = bytes.Pop();
            output += sybmols[pop % sybmols.Length];
        }
        return output;
    }
}

Единственный недостаток - когда вы создаете новые строки в SQL. Таким образом, вы должны создать аналогичную функцию sql.

Будем рады получить любого критика в мой адрес.

0 голосов
/ 21 июня 2009

Следуйте советам Клетуса, с дополнительным предостережением это во многом зависит от того, что вы сортируете. Никогда, никогда не используйте GUID. У GUID есть целый ряд недостатков, и только один или два достоинства.

0 голосов
/ 31 мая 2009

Я задал похожий вопрос, в котором есть несколько ответов, которые могут помочь. Репликация, кажется, самое большое преимущество использования GUID.

Причины не использовать автоматически увеличивающееся число для первичного ключа

0 голосов
/ 31 мая 2009

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

Было бы неплохо, если бы базы данных могли обеспечивать встроенную поддержку автоинкрементов с "префиксами". Поэтому в одной базе данных я получаю идентификаторы, такие как X1, X2, X3 ... и т. Д., Тогда как в другой базе данных это могут быть Y1, Y2, Y3 ... и т. Д.

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