Как вам нравятся ваши первичные ключи?[закрыто]

https://stackoverflow.com/questions/404040

03-07-2019
|

Вопрос

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

Int / BigInt, которые автоматически создаются, являются достаточно хорошими первичными ключами.
Должно быть не менее 3 столбцов, составляющих первичный ключ.
Id, GUID и удобочитаемые идентификаторы строк - все они должны обрабатываться по-разному.

Каков наилучший подход для PKs?Было бы здорово, если бы вы могли обосновать свое мнение.Есть ли лучший подход, чем описанный выше?

Редактировать:У кого-нибудь есть простой образец / алгоритм для генерации удобочитаемых идентификаторов для строк, которые хорошо масштабируются?

Решение

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

Автоинкрементные целые числа должны быть вашими по умолчанию, и нет их использование должно быть оправдано.

Другие советы

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

Например, в таблице названий и кодов штатов (США) либо имя, либо код могут быть первичным ключом - они представляют собой два разных ключа-кандидата, и один из них (обычно более короткий - код) выбирается в качестве первичного ключа.В теории функциональных зависимостей (и присоединяемых зависимостей - от 1NF до 5NF ) решающее значение имеют ключи-кандидаты, а не первичный ключ.

В качестве контрпримера, человеческие имена обычно являются плохим выбором для первичного ключа.Есть много людей, которые носят имя "Джон Смит" или какие-то другие подобные имена;даже принимая во внимание отчества (помните:не у всех он есть (например, у меня его нет), есть много возможностей для дублирования.Следовательно, люди не используют имена в качестве первичных ключей.Они изобретают искусственные ключи, такие как номер социального страхования (SSN) или Номер сотрудника, и используют их для обозначения личности.

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

Поэтому, когда дело доходит до определения первичного ключа данной таблицы, вы должны посмотреть, что представляет эта таблица.Какой набор или наборы значений столбцов в таблице однозначно идентифицируют каждую строку в таблице?Это ключи-кандидаты.Теперь, если каждый потенциальный ключ состоит из 4 или 5 столбцов, то вы можете решить, что они слишком неуклюжи для создания хорошего первичного ключа (в первую очередь из-за краткости).В таких обстоятельствах вы могли бы ввести суррогатный ключ - искусственно сгенерированный номер.Очень часто (но не всегда) для суррогатного ключа достаточно простого 32-битного целого числа.Затем вы назначаете этот суррогатный ключ в качестве первичного ключа.

Однако, вы должен по-прежнему убедитесь, что все другие ключи-кандидаты (поскольку суррогатный ключ также является ключом-кандидатом, как и выбранный первичный ключ) поддерживаются как уникальные идентификаторы - обычно путем наложения уникального ограничения на эти наборы столбцов.

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

В некоторых отношениях это довольно жесткая точка зрения.

У меня нет особых проблем с использованием GUID, когда они необходимы, но они, как правило, большой (например, в 16-64 байтах), и они используются слишком часто.Очень часто было бы достаточно совершенно правильного 4-байтового значения.Использование GUID, где было бы достаточно 4-байтового значения, приводит к пустой трате дискового пространства и замедляет даже индексированный доступ к данным, поскольку на страницу индекса приходится меньше значений, поэтому индекс будет более глубоким и для получения информации потребуется прочитать больше страниц.

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

Суррогатные ключи полезны, когда ни один другой атрибут или набор атрибутов в таблице не подходит для однозначной идентификации строк.
Естественные ключи предпочтительнее, когда это возможно, чтобы сделать таблицу более понятной для человека.Естественные ключи также позволяют внешнему ключу в зависимой таблице содержать реальное значение вместо суррогатного идентификатора.Например.когда вам нужно хранить state (КАЛИФОРНИЯ, Техас, Нью-Йорк) с таким же успехом вы могли бы использовать char(2) естественный ключ вместо int.
Используйте составные первичные ключи там, где это уместно.Не добавляйте "id" суррогатный ключ без необходимости, когда существует совершенно хороший составной ключ (это особенно верно для таблиц "многие ко многим").Указание ключа из трех столбцов в каждой таблице - абсолютная бессмыслица.
Идентификаторы GUID - это решение, когда вам нужно сохранить уникальность на нескольких сайтах.Они также удобны, если вам нужно, чтобы значения в первичном ключе были уникальными, но не упорядоченными или последовательными.
INT противБОЛЬШОЙ ЧЛЕН:нечасто бывает, чтобы таблица требует 64-разрядный диапазон для первичных ключей, но с ростом доступности 64-разрядного оборудования он не должен быть обременительным и дает больше гарантий того, что вы не будете переполняться.INT, конечно, меньше, поэтому, если пространство дорого, это может дать небольшое преимущество.

Мне нравится Блог Программиста баз данных как источник такого рода информации.

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

Мне нравится, когда моя работа уникальна.

Я всегда пользуюсь суррогатным ключом.Суррогатный ключ (обычно столбец идентификатора, автоинкремент или GUID) - это ключ, в котором ключ отсутствует в самих данных.С другой стороны, естественный ключ - это тот, который сам по себе однозначно идентифицирует строку.Насколько я могу судить по жизни, таких почти нет реальный естественные ключи.Даже такие вещи, как SSN, в Соединенных Штатах не являются естественным ключом.Составные первичные ключи - это катастрофа, которая только и ждет своего часа.Вы не можете редактировать какие-либо из этих данных (что является основным недостатком любого естественного ключа, составного или нет), но хуже всего то, что с составным ключом теперь вам приходится сохранять эти ключевые данные в каждой связанной таблице.Какая огромная трата времени.

Теперь, для выбора суррогатного ключа, я использую столбцы identity (я работаю в основном в MS SQL Server).Идентификаторы GUID слишком велики, и Microsoft рекомендует против используя их в качестве PK.Если у вас несколько серверов, все, что вам нужно сделать, это увеличить 10 или 20, или как вы считаете, максимальное количество серверов, с которыми вам когда-либо понадобится синхронизировать / расширять, и просто включить начальное значение для каждой таблицы на каждом последующем сервере, и у вас никогда не будет столкновения данных.

Конечно, из-за увеличения я делаю столбец identity BigInt (иначе известный как длинный [64 бита]).

Немного посчитав, даже если вы сделаете приращение 100, у вас все равно может быть 92 233 720 368 547 758 (> 92 квадриллионов) строк в вашей таблице.

Я думаю, что использование слова "Первичный" во фразе "Первичный" ключ в реальном смысле вводит в заблуждение.

Во-первых, используйте определение, согласно которому "ключ" - это атрибут или набор атрибутов, которые должны быть уникальными в таблице,

Тогда наличие любого ключа служит нескольким часто взаимоисключающим целям.

Использовать в качестве условий объединения к одной или нескольким записям в дочерних таблицах, которые имеют отношение к этой родительской таблице.(Явное или неявное определение внешнего ключа в этих дочерних таблицах)
(связано) Обеспечение того, чтобы дочерние записи должны иметь родительскую запись на родительской вкладке; e (Дочерняя таблица FK должна существовать как ключ в родительской таблице)
Чтобы увеличить количество запросов, которым необходимо быстро найти определенную запись / строку в таблице.
Обеспечить согласованность данных путем предотвращения вставки в таблицу повторяющихся строк, представляющих один и тот же логический объект.(Это часто называют "естественным" ключом, и он должен состоять из атрибутов таблицы (сущности), которые относительно инвариантны.)

Очевидно, что любой бессмысленный, ненатуральный ключ (например, GUID или автоматически сгенерированное целое число) полностью неспособен удовлетворять # 4.

Но часто, со многими (большинством) таблицами, абсолютно естественный ключ, который может предоставлять # 4, часто будет состоять из нескольких атрибутов и быть чрезмерно широким или настолько широким, что использование его для целей # 1, # 2 или # 3 приведет к неприемлемым последствиям для производительности.

Ответ прост.Используйте и то, и другое.Используйте простой автоматически генерируемый интегральный ключ для всех объединений и FK в других дочерних таблицах, но убедитесь, что каждая таблица, требующая согласованности данных (очень немногие таблицы этого не делают), имеет альтернативный естественный уникальный ключ, который предотвратит вставку несогласованных строк данных...Кроме того, если у вас всегда есть и то, и другое, то все возражения против использования естественного ключа (что, если он изменится?Я должен изменить каждое место, где на него ссылаются как на FK), становится спорным, поскольку вы не используете его для этого...Вы используете его только в той таблице, где это PK, чтобы избежать несогласованных дублирующих данных...

Что касается GUID, будьте очень осторожны, используя их, так как использование guid в индексе может привести к фрагментации индекса.Наиболее распространенные алгоритмы, используемые для их создания, помещают "случайную" часть guid в позиции наиболее значимых битов...Это увеличивает требования к регулярной дефрагментации / переиндексации индекса по мере добавления новых строк.

Немного не по теме, но я чувствую себя обязанным вмешаться...

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

Одна вещь, которую вы никогда не должны делать, - это использовать смарт-ключ.Это ключ, в котором информация о записи закодирована в самом ключе, и в конечном итоге он вас укусит.

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

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

Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1

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

Пожалуйста, пожалуйста, пожалуйста, если вы пишете код, который мне когда-либо придется поддерживать, пожалуйста, не используйте смарт-ключ!

Я поклонник автоматического увеличения в качестве первичного ключа.В глубине души я знаю, что это отговорка, но это позволяет так легко сортировать данные по времени их добавления (УПОРЯДОЧИВАТЬ ПО идентификатору DESC, например).

3 столбца звучит ужасно грубо для человеческого понимания.

И это компромисс - сколько реляционных возможностей вам нужно, по сравнению с тем, чтобы сделать ЭТУ ТАБЛИЦУ ПРЯМО ЗДЕСЬ понятной для человека, опрашивающего ее (по сравнению с хранимой процедурой или программным интерфейсом).

автоматическое увеличение - это для нас, людей.:-(

Как правило, это зависит от обстоятельств.

Лично мне нравятся целые числа с автоинкрементом.

Но одну вещь я могу вам сказать: никогда не доверяйте данным из других источников в качестве своего ключа.Клянусь, каждый раз, когда я это делал, он возвращался, чтобы укусить меня.Ну, больше никогда!

Должно быть не менее 3 столбцов, составляющих первичный ключ.

Я этого не понимаю.

Вы говорите о "естественном ключе", например"имя и дата рождения"?Естественный ключ может быть идеальным, если он существует, но большинство кандидатов на естественный ключ либо не уникальны (несколько человек с одинаковым именем), либо непостоянны (кто-то может изменить свое имя).

Int / BigInt, которые автоматически создаются, являются достаточно хорошими первичными ключами.

Я предпочитаю Guid.Потенциальная проблема с автоинкрементом заключается в том, что значение (например,"идентификатор заказа") присваивается экземпляром базы данных (например,с помощью "базы данных продаж") ...который не будет работать полностью (вместо этого вам понадобятся составные ключи), если вам когда-нибудь понадобится объединить данные, созданные более чем одним экземпляром базы данных (напримериз нескольких офисов продаж, каждый со своей собственной базой данных).

Руководство пользователя

Будьте осторожны, если это будет по-настоящему, по-НАСТОЯЩЕМУ В САМОМ ДЕЛЕ большая база данных, большая загрузка и быстрый доступ.

На моей последней работе, где у нас были базы данных объемом от 100 до 500 миллионов записей, наши специалисты по базам данных решительно выступали против GUID и за десятичное число соответствующего размера.Они посчитали, что (в Oracle) разница в размере внутренней памяти для строкового Guid - vs- a десятичного значения будет иметь очень заметную разницу при поиске.(Большие ключи = более глубокие деревья для обхода)

Случайный характер идентификаторов GUID также значительно снижает коэффициент заполнения индексных страниц - это значительно увеличивает разрыв данных и дисковый ввод-вывод.

Автоматическое увеличение столбцов.Я могу заставить свой код беспрепятственно работать с SQL Server или Oracle, один из которых использует identity, другой - sequences через мой DAL, и я не могу быть счастливее.Я согласен, идентификаторы GUID иногда необходимы, если вы выполняете репликацию или отправляете данные, чтобы получить их позже после обработки.

Я всегда использовал суррогатный ключ - автоматически вводимое целое число под названием "id".Я вижу множество причин для этого, даже когда очевиден другой вариант:

Последовательность
Независимый от данных (уникальный, не уничтожаемый изменениями формата)
Удобочитаемый для человека

..и нет разумной причины не делать этого:

Двусмысленность в объединениях?- Таблицы псевдонимов - лучшая практика, ИМХО
Оптимальные столы?- Удаление одного байта на запись - преждевременная оптимизация, ИМХО
Решение для каждого стола?- Больше не соответствует
Проблемы с масштабированием?- А?Почему?
Иерархическая структура данных?- Это денормализация, совершенно другой предмет религии.Достаточно сказать, что я фанат в некоторых случаях в теории, но никогда на практике :)

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

Это классическое "это зависит".Для каждого проекта нет единственно правильного ответа.Мне нравятся разные вещи для разных ситуаций.Это зависит от того, использую ли я ORM и что он поддерживает.Это зависит от общей архитектуры (распределенной или нет и т.д.).Просто выберите тот, который, по вашему мнению, сработает, и переходите к спорам о табуляции и пробелах.

Я обычно использую вариант № 1 или № 3 в зависимости от размера, количества подключающихся пользователей и того, является ли это ситуация с несколькими серверами баз данных или нет.

Вариант № 2 для меня не имеет особого смысла.Если какого-либо одного из трех недостаточно для идентификации уникальной записи, то возможно (без дополнительных манипуляций), чтобы во всех трех столбцах отображались две записи с одинаковыми значениями.Если вы хотите обеспечить уникальность для любой комбинации из этих трех, то просто добавьте для них индекс.

Я использую только автоинкрементный int или GUID.в 99% случаев я использую автоматическое увеличение int.Это просто то, чему меня научили пользоваться, когда я впервые узнал о базах данных, и я никогда не сталкивался с причиной не использовать их (хотя я знаю причины, по которым GUID был бы лучше).

Мне нравится автоматическое увеличение целых чисел, потому что это улучшает читаемость.Например, я могу сказать "взгляните на запись 129383", и кому-то довольно легко зайти и найти ее.С GUID это практически невозможно сделать.

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

Не слишком ли сложное определение первичного ключа?Позволяет ли это избежать ненужных сложностей ради следования "передовой практике"?
Существует ли лучший возможный первичный ключ, для обработки которого потребовалось бы меньше накладных расходов для базы данных (т. е.ЦЕЛОЕ число противVARCHAR и т.д.)?
Могу ли я АБСОЛЮТНО уверен, что инвариант уникальности и определенности моего первичного ключа не изменится?

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

Надеюсь, это поможет внести некоторую ясность...

Способ, которым я подхожу к первичным ключам (и я считаю, что это лучший), заключается в том, чтобы избегать подхода "по умолчанию".Это означает, что вместо того, чтобы просто нажимать на автоинкрементное целое число и называть его днем, я смотрю на проблему и говорю: "есть ли столбец или группа столбцов, которые всегда будут неизменными и не изменятся?" Если ответ "да", то я придерживаюсь такого подхода.

Почти всегда целые числа.

У них есть и другие веские причины, помимо того, что они меньше по размеру и быстрее обрабатываются.Что бы вы предпочли записать - "404040" или "3463b5a2-a02b-4fd4-aa0f-1d3c0450026c"?

Лишь слегка актуально, но одна вещь, которую я начал делать недавно, когда у меня появились небольшие таблицы классификации (по сути, те, которые будут представлять перечисления в коде), заключается в том, что я сделаю первичный ключ символом (3) или символом (4).Затем я делаю эти первичные ключи репрезентативными для значения поиска.

Например, у меня есть система квотирования для наших внутренних торговых агентов.У нас есть "Категории затрат", которым присваивается одна из позиций каждой строки предложения...Итак, у меня есть таблица поиска типов под названием "tCostCategories", где первичным ключом является "MTL", "SVC", "TRV", "TAX", "ODC".В других столбцах таблицы поиска хранятся дополнительные сведения, такие как обычные английские значения кодов, "Материал", "Услуга", "Проезд", "Налоги", "Прочие прямые расходы" и так далее.

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

1 партнерский номер $40 млн
2 Другие части по номеру $29.99 SVC
3 партнера по 2 $150 TRV

Намного проще использовать int для представления категорий, а затем связать 1, 2, 3 по всем строкам - у вас есть данные прямо перед вами, и на производительность, похоже, это никак не влияет (не то, чтобы я действительно тестировал).

Что касается настоящего вопроса...Мне нравятся уникальные идентификаторы RowGUID.Я не уверен в этом на 100%, но разве не у всех строк все равно есть внутренние rowguid'ы??Если это так, то использование RowGuid на самом деле заняло бы меньше места, чем целые числа (или что-либо еще, если уж на то пошло.) Все, что я знаю, это то, что если это достаточно хорошо для M $, чтобы использовать в GreatPlains, то это достаточно хорошо и для меня.(Должен ли я пригнуться??)

О, еще одна причина, по которой я использую GUID - я использую иерархическую структуру данных.То есть у меня есть таблица "Компания" и таблица "Поставщик", для которых Первичные ключи совпадают.Но у меня также есть таблица "Производитель", которая также "наследуется" от Company.Поля, которые являются общими для Поставщиков и Изготовителей, не отображаются в этих таблицах - они отображаются в разделе Компания.В этой настройке использование int намного более болезненно, чем Guid.По крайней мере, вы не можете использовать первичные ключи идентификации.

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

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

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

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

Путеводители.точка.

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

обновите, чтобы прояснить мое заявление.

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

При использовании GUID вы можете сгенерировать идентификатор в любом месте.Он может быть сгенерирован удаленным сервером, вашим веб-приложением, внутри самой базы данных или даже внутри нескольких баз данных в ситуации с несколькими мастерами.

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

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

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

Наше последнее приложение проходит через период интенсивных вставок, который длится около месяца.После этого более 90% запросов выбираются для составления отчетов.Чтобы увеличить пропускную способность, я могу подключить дополнительные серверы БД в течение этого большого периода вставки;а позже легко объединить их в единую базу данных для составления отчетов.Попытка сделать это с помощью целых чисел была бы абсолютным кошмаром.

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

Это сложный вопрос, независимо от того, осознавали вы это или нет.Может подпадать под раздел этого часто задаваемого вопроса о StackOverflow.

Какие вопросы я не должен задавать здесь?

Избегайте задавать вопросы, которые носят субъективный характер, содержат аргументы или требуют длительного обсуждения.Это место для вопросов, на которые можно получить ответы!

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow