В довольно оживленной дискуссии в моей команде меня заставили думать, что большинство людей предпочитают как первичные ключи. У нас были следующие группы -
Какой лучший подход для ПК? Было бы здорово, если бы вы могли оправдать свое мнение. Есть ли лучший подход, что выше?
EDIT: у кого-нибудь есть простой образец/алгоритм для генерации человеческих читаемых идентификаторов для строк, которые хорошо масштабируются?
Если вы собираетесь выполнять какую-либо синхронизацию между базами данных с случайно подключенными приложениями, вы должны использовать GUID для своих основных ключей. Это отчасти боль для отладки, поэтому, кроме этого, я склонен придерживаться ints, что автоинкремент.
Автоинкремент ints должен быть вашим значением по умолчанию, а использование не должно быть оправдано.
Я не вижу ответа, который указывает (что я считаю) на самом деле фундаментальным моментом, а именно, что первичный ключ - это то, что гарантирует, что вы не получите две записи в таблице для одного и того же реального мира entity (как смоделировано в базе данных). Это наблюдение помогает установить, что хорошо, а что плохой выбор для первичного ключа.
Например, в таблице имен и кодов состояний (США) имя или код могут быть первичным ключом - они представляют собой два разных ключа-кандидата, а один из них (как правило, короче - код) выбранный в качестве первичного ключа. В теории функциональных зависимостей (и зависимостей соединения - от 1NF до 5NF - ключевыми являются ключи-кандидаты, а не первичный ключ.
Для встречного примера имена людей обычно делают плохой выбор для первичного ключа. Есть много людей, которые идут по имени "Джон Смит" или некоторые другие подобные имена; даже принимая во внимание средние имена (помните: не у каждого есть одно - например, я этого не делаю), есть много возможностей для дублирования. Следовательно, люди не используют имена в качестве первичных ключей. Они изобретают искусственные ключи, такие как номер социального страхования (SSN) или номер сотрудника и используют их для обозначения личности.
Идеальный первичный ключ - короткий, уникальный, запоминающийся и естественный. Из этих характеристик уникальность является обязательной; остальные должны сгибаться, учитывая ограничения данных реального мира.
Когда дело доходит до определения первичного ключа данной таблицы, вы должны посмотреть, что представляет эта таблица. Какие установленные или заданные значения столбцов в таблице однозначно идентифицируют каждую строку в таблице? Это кандидатские ключи. Теперь, если каждый ключ кандидата состоит из 4 или 5 столбцов, вы можете решить, что они слишком неуклюжи, чтобы сделать хороший первичный ключ (в первую очередь, из-за короткого замыкания). В этих обстоятельствах вы можете ввести суррогатный ключ - искусственно созданный номер. Очень часто (но не всегда) достаточно простого 32-битного целого для суррогатного ключа. Затем вы определяете этот суррогатный ключ как первичный ключ.
Тем не менее, вы должны по-прежнему гарантировать, что другие ключи-кандидаты (для суррогатного ключа также являются ключом-кандидатом, а также выбранным первичным ключом) поддерживаются как уникальный идентификатор - обычно путем размещения уникальное ограничение для этих наборов столбцов.
Иногда людям трудно определить, что делает уникальную строку, но должно быть что-то сделать, потому что просто повторение части информации не делает ее более правдой. И если вы не будете осторожны и получите две (или более) строки, предназначенные для хранения одной и той же информации, а затем вам необходимо обновить информацию, существует опасность (особенно если вы используете курсоры), что вы обновите только одну строку а не каждая строка, поэтому строки не синхронизированы, и никто не знает, какая строка содержит правильную информацию.
В некотором отношении это довольно жесткое представление.
У меня нет особых проблем с использованием GUID, когда они нужны, но они имеют тенденцию быть большими (как в 16-64 байтах), и они используются слишком часто. Очень часто достаточно хорошего 4-байтового значения. Использование GUID, где 4-байтовое значение будет достаточным, уменьшает дисковое пространство и замедляет даже индексированный доступ к данным, поскольку на индексной странице меньше значений, поэтому индекс будет более глубоким, и больше страниц нужно прочитать, чтобы перейти к информация.
Это только религиозная проблема, потому что люди ищут универсальный правильный ответ. Тот факт, что и ваша команда, и этот поток SO демонстрируют столь большое несогласие, должны быть ключом к тому, что есть веские причины использовать все решения, которые вы описываете, в разных обстоятельствах.
state (CA, TX, NY), вы можете использовать char(2) естественный ключ вместо int.id" без необходимости, когда существует совершенно хороший составной ключ (это особенно верно во многих таблицах). Мандат для трехколоночного ключа в каждой таблице является абсолютной бессмыслицей.Мне нравится Блог программиста базы данных в качестве источника для такого рода информации.
3 столбца для первичного ключа? Я бы сказал, что столбцы должны иметь соответствующие уникальные ограничения, как того требуют бизнес-правила, но у меня все равно будет отдельный ключ суррогата. Сложные ключи означают, что бизнес-логика входит в ключ. Если логика изменяется, вся ваша схема завинчивается.
Мне нравится моя уникальная.
Я думаю, что использование слова "Первичный" во фразе "Первичный" Ключ в реальном смысле, вводит в заблуждение.
Сначала используйте определение, что "ключ" является атрибутом или набором атрибутов, которые должны быть уникальными в таблице,
Затем, если любой ключ служит нескольким часто взаимно непоследовательным целям.
Чтобы увеличить perforamce запросов, которым необходимо быстро найти определенную запись/строку в таблице.
Чтобы обеспечить согласованность данных, не допуская, чтобы повторяющиеся строки, представляющие один и тот же логический объект, были вставлены в таблицу. (Это часто называют "естественным" ключом и должно состоять из атрибутов таблицы (сущности), которые относительно инвариантны.)
Очевидно, что любой несущественный, неестественный ключ (например, GUID или автогенерированное целое полностью не способен удовлетворить # 4.
Но часто, со многими (наиболее) таблицами, вполне естественный ключ, который может обеспечить # 4, часто будет состоять из нескольких атрибутов и быть слишком широким или настолько широким, чтобы использовать его для целей # 1, # 2 или # 3 приведет к неприемлемым последствиям производительности.
Ответ прост. Используйте оба варианта. Используйте простой автоматический генератор интегрального ключа для всех Joins и FK в других дочерних таблицах, но убедитесь, что для каждой таблицы, для которой требуется согласованность данных (в очень немногих таблицах нет), есть альтернативный естественный уникальный ключ, который предотвратит вставку несогласованных строк данных... Плюс, если у вас всегда есть оба, то все возражения против использования естественного ключа (что, если он изменится? Я должен изменить каждое место, на которое он ссылается, как FK) становится спорным, поскольку вы не используете его для этого... Вы используете его только в одной таблице, где это ПК, чтобы избежать непоследовательных дублирующих данных...
Что касается GUID, будьте очень осторожны с ними, так как использование указаний в индексе может привести к фрагментации индекса шланга. Наиболее распространенные алгоритмы, используемые для их создания, помещают "случайную" часть указателя в наиболее значимые позиции бит... Это увеличивает потребность в регулярной дефрагментации индекса/переиндексации при добавлении новых строк.
Я всегда использую суррогатный ключ. Суррогатный ключ (обычно это столбец идентификации, автоинкремент или GUID) - это тот, в котором ключ отсутствует в самих данных. С другой стороны, естественным ключом является тот, который сам по себе однозначно идентифицирует строку. Насколько я могу судить в жизни, вряд ли есть какие-то реальные естественные ключи. Даже такие вещи, как SSN в Соединенных Штатах, являются естественным ключом. Сложные первичные ключи - это катастрофа, ожидающая своего появления. Вы не можете редактировать ни одну из этих данных (что является основным недостатком любого естественного ключа, составного или нет), но хуже того, что с помощью составного ключа теперь вы должны увековечить эти ключевые данные в каждой связанной таблице. Какая гигантская трата.
Теперь, для выбора суррогатного ключа, я придерживаюсь идентификационных столбцов (я работаю в основном на MS SQL Server). GUID слишком велики, и Microsoft рекомендует не использовать их в качестве ПК. Если у вас несколько серверов, все, что вам нужно сделать, это сделать прирост 10 или 20 или то, что вы считаете максимальным количеством серверов, которые вам понадобятся для синхронизации или расширения, и просто включить семя для каждой таблицы на каждом последующем сервере, и у вас никогда не будет столкновения данных.
Конечно, из-за приращения я делаю столбец идентификатора BigInt (иначе известный как длинный [64 бит]).
Выполняя немного математики, даже если вы делаете инкремент 100, у вас все еще может быть 92,233,720,368,547,758 ( > 92 квадриллиона) строк в таблице.
Одна вещь, которую вы никогда не должны делать, - это использовать интеллектуальный ключ. Это ключ, когда информация о записи закодирована в самом ключе, и это в конечном итоге укусит вас.
Я работал в одном месте, где основным ключом был идентификатор учетной записи, который представлял собой комбинацию букв и цифр. Я не помню никаких особенностей, но, например, те учетные записи, которые были определенного типа, были бы в диапазоне 600 и другого типа, начинались с 400. Это было здорово, пока этот клиент не решил задать оба виды работ. Или изменили тип работы, которую они сделали.
В другом месте использовалось расположение в дереве в качестве первичного ключа для записей. Таким образом, будут записи, подобные следующим.
Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1
Конечно, первое, чего хотели клиенты, - это способ перемещения предметов на дереве. Весь пакет программного обеспечения умер до того, как это произошло.
Пожалуйста, пожалуйста, пожалуйста, если вы пишете код, который мне когда-либо нужно поддерживать, пожалуйста, не используйте интеллектуальный ключ!
Немного не по теме, но я чувствую себя вынужденным звонить...
Если ваш первичный ключ является GUID, не сделать его кластеризованным индексом. Поскольку идентификаторы GUID не являются последовательными, данные будут переупорядочены на диске в течение почти каждой вставки. (Yuck.) Если использовать GUID как первичные ключи, они должны быть некластеризованными индексами.
Я являюсь поклонником автоинкремента в качестве первичного ключа. Я глубоко понимаю в своем сердце, что это откат, но он упрощает сортировку данных, когда он был добавлен (ORDER BY ID DESC, f'r instance).
3 колонки звучат ужасно суровыми для человеческого разбора.
И что компромисс - какая из реляционных возможностей вам нужна, в сравнении с тем, что ЭТО ТАБЛИЦА ПРАВИЛЬНО ЗДЕСЬ понятна человеку, опросившему его (по сравнению с хранимой процедурой или программным интерфейсом).
автоинкремент для нас - людей.: - (
Как правило, это зависит.
Лично мне нравится автоинкремент ints.
Но одно можно сказать вам: никогда не доверять данным из других источников в качестве своего ключа. Клянусь, каждый раз, когда я делал это, он возвращался, чтобы укусить меня. Ну, больше никогда!
Должно быть по крайней мере 3 столбца, которые составляют первичный ключ.
Я не понимаю этого.
Вы говорите о "естественном ключе", например. "имя и дата рождения"? Естественный ключ может быть идеальным, если он существует, но большинство кандидатов для естественного ключа либо не уникальны (несколько человек с одним и тем же именем), либо не являются постоянными (кто-то может изменить свое имя).
Int/BigInt, автоинкремент которого является достаточно хорошими первичными ключами.
Я предпочитаю Guid. Потенциальная проблема с автоинкрементами заключается в том, что значение (например, "идентификатор заказа" ) присваивается экземпляром базы данных (например, по "базе данных продаж" )... которая не будет полностью работать (вместо этого вам понадобятся составные ключи), если вам когда-либо понадобится объединить данные, созданные более чем одним экземпляром базы данных (например, из нескольких офисов продаж, каждый со своей собственной базой данных).
RE GUID
Следите за тем, действительно ли это будет действительно реальной DOALY ДЕЙСТВИТЕЛЬНО, большой нагрузкой и быстрым доступом.
На моей последней работе, где у нас были базы данных от 100 до 500 миллионов записей, наши ребята из базы данных решительно возражали против GUID и десятичного числа соответствующего размера. Они чувствовали, что (под Oracle) разница в размерах во внутреннем хранилище для строки Guid - vs - десятичное значение будет иметь очень заметную разницу в поиске. (Большие клавиши = более глубокие деревья для перемещения)
Случайный характер GUID также значительно уменьшает коэффициент заполнения для страниц индекса - это значительно увеличивает разрыв и дисковый ввод-вывод.
Автоматическое увеличение столбцов. Я могу сделать мой код без проблем совместимым с SQL Server или Oracle, один из которых использует идентификацию другого, используя последовательности через мой DAL, и я не мог быть счастливее. Я согласен с тем, что GUID иногда необходимы, если вы делаете репликацию или отправляете данные, чтобы получить их позже при обработке афер.
Я всегда использовал суррогатный ключ - автоинкрементное целое, называемое "id". Я могу видеть множество причин, чтобы сделать это, даже когда другой вариант очевиден:
... и нет разумной причины не:
разумные причины, против которых я еще не думал или не встречался, всегда приветствуются...
Это классический "это зависит". Там нет ни одного правильного ответа для каждого проекта. Мне нравятся разные вещи для разных ситуаций. Это зависит от того, использую ли я ORM и что он поддерживает. Это зависит от общей архитектуры (распределенной или нет, и т.д.). Просто выберите тот, который, по вашему мнению, будет работать, и переходите к аргументам над вкладками и пробелами.
Я предпочитаю использовать параметр # 1 или # 3 в зависимости от размера, количества подключаемых людей и от того, является ли это ситуацией с несколькими серверами баз данных или нет.
Вариант № 2 для меня не имеет большого значения. Если какой-либо из трех недостаточно для идентификации уникальной записи, то это возможно (без прохождения дополнительных махинаций), две из двух записей отображаются с одинаковыми значениями во всех трех столбцах. Если вы хотите применить уникальность в любой комбинации из трех, просто добавьте для них индекс.
Guids.period.
В случае, если вам нужно масштабировать или вам нужно назначить первичный ключ альтернативным способом, они станут вашим другом. Вы можете добавлять индексы для всего остального.
чтобы уточнить мой оператор.
Я работал над множеством разных сайтов. От небольших сделок с одним сервером до крупных, поддерживаемых несколькими БД и веб-серверами. Там, безусловно, были приложения, которые были бы прекрасны с автоматическим инкрементным ints как первичными ключами. Тем не менее, это не соответствует модели того, как я это делаю.
При использовании GUID вы можете сгенерировать идентификатор в любом месте. Он может быть сгенерирован удаленным сервером, вашим веб-приложением в самой базе данных или даже в нескольких базах данных в ситуации с несколькими серверами.
С другой стороны, автоматический инкрементированный INT может быть безопасно создан только в первичной базе данных. Опять же, это может быть хорошо, если у вас есть приложение, которое будет тесно связано с тем, что один сервер базы данных резервного копирования и масштабирование не является чем-то, что вас беспокоит.
Конечно, использование GUID означает, что вы должны иметь ночные процессы переиндексации. Однако, если вы используете что-либо, кроме автоматического увеличения INT, вы все равно должны это делать. Черт, даже если INT является основным, вероятно, у вас есть другие индексы, которые необходимо восстановить для борьбы с фрагментацией. Поэтому использование GUID не означает, что еще одна проблема возникает, потому что эти задачи нужно выполнять независимо.
Если вы посмотрите на более крупные приложения, вы заметите что-то важное: все они используют кодированные GUID в кодировке Base64 в качестве ключей. Причина этого проста, использование GUID позволяет легко масштабироваться, тогда как при попытке масштабирования INTs может быть много обручей.
В наше последнее приложение входит период тяжелых вставок, который длится около месяца. После этого 90 +% запросов выбираются для отчетности. Чтобы увеличить емкость, я могу вызвать дополнительные серверы БД в течение этого большого периода вставки; и позже легко объединить их в единую БД для отчетности. Попытка сделать это с помощью INT была бы абсолютным кошмаром.
Совершенно откровенно, в любое время, когда вы кластеризуете базу данных или настраиваете репликацию, сервер БД будет требовать, чтобы у вас есть GUID в таблице. Итак, если вы считаете, что ваша система, возможно, потребуется расти, выберите тот, который хорош.
Я использую только auto-increment int или GUID. В 99% случаев я использую auto-increment int. Это то, чему меня научили использовать, когда я впервые узнал о базах данных и никогда не сталкивался с тем, что не использовал их (хотя я знаю причины, по которым GUID будет лучше).
Мне нравится auto increment ints, потому что он помогает с удобочитаемостью. Например, я могу сказать "взгляните на запись 129383", и довольно легко кому-то пойти и найти ее. С GUID, который почти невозможно сделать.
Пройдя базовый дефиниционный ответ, то, что составляет хороший первичный ключ, остается в значительной степени религией и нарушает аргументы в комнате. Если у вас есть что-то, что есть и всегда будет отображаться однозначно для отдельной строки, тогда он будет работать нормально как первичный ключ. В прошлом, есть и другие соображения:
Последнее, вероятно, приводит к тому, что большинство людей используют такие вещи, как GUID или самонастраивающиеся целые столбцы, потому что полагаться на такие вещи, как адреса, номера телефонов, имена и фамилии и т.д., просто не сокращайте его. Единственный инвариант, о котором я могу думать, это SSN, но тогда я даже не уверен на 100% о тех, кто остается навсегда уникальным.
Надеюсь, это поможет добавить ясность...
То, как я приближаюсь к основным ключам (и я считаю, что это лучше), заключается в том, чтобы не использовать подход "по умолчанию". Это означает, что вместо просто пошатывания целочисленного числа с автоматическим добавлением и вызова его в день я смотрю на проблему и говорю: "Есть ли столбец или группа столбцов, которые всегда будут неопределенными и не изменятся?" Если ответ "да", я принимаю этот подход.
Почти всегда целые числа.
У них есть другие веские причины, кроме того, что они меньше/быстрее обрабатываются. Что бы вы предпочли записать - "404040" или "3463b5a2-a02b-4fd4-aa0f-1d3c0450026c"?
Только немного актуально, но я недавно начал заниматься, когда у меня есть небольшие таблицы классификации (по существу те, которые будут представлять ENUM в коде), что я сделаю первичный ключ char (3) или char (4). Затем я делаю эти первичные ключи отображающими значение поиска.
Например, у меня есть система цитирования для наших внутренних агентов по продажам. У нас есть "Категории затрат", которые присваиваются каждой позиции кавычки одной из... Поэтому у меня есть таблица поиска типов, называемая "tCostCategories", где первичный ключ - "MTL", "SVC", "TRV", "TAX", "ОДС". Другие столбцы в таблице поиска хранят более подробную информацию, например, нормальные английские значения кодов, "Материал", "Сервис", "Путешествия", "Налоги", "Другие прямые затраты" и т.д.
Это действительно хорошо, потому что он не использует больше места, чем int, и когда вы смотрите на исходные данные, вам не нужно связывать таблицу поиска, чтобы узнать, что это за значение. Например, строка цитаты может выглядеть так:
1 PartNumber $40 MTL
2 OtherPartNumber $29.99 SVC
3 PartNumber2 $150 TRV
Это намного проще, если использовать int для представления категорий, а затем привязать 1, 2, 3 на всех строках - у вас есть данные прямо перед вами, и производительность не кажется вообще затронутой (не что я действительно испытал.)
Что касается реального вопроса... Мне нравятся уникальные идентификаторы RowGUID. Я не на это 100%, но не все ли строки имеют встроенный RowGuid? Если это так, то использование RowGuid на самом деле займет меньше места, чем ints (или что-нибудь еще в этом случае.) Все, что я знаю, это то, что если это будет достаточно для использования M $в GreatPlains, то это будет достаточно для меня. (Должен ли я утка??)
Еще одна причина, по которой я использую GUID - я использую иерархическую структуру данных. То есть у меня есть таблица "Компания" и таблица "Поставщик", для которой совпадают Первичные ключи. Но у меня также есть таблица "Производитель", которая также "наследуется" от Компании. Поля, которые являются общими для поставщиков и изготовителей, не отображаются в этих таблицах - они появляются в Компании. В этой настройке использование int намного больнее, чем Guids. По крайней мере, вы не можете использовать первичные ключи идентификации.
Мне нравятся естественные ключи, когда я могу им доверять. Я готов заплатить небольшую цену за производительность, чтобы использовать ключи, которые имеют смысл для экспертов по теме.
Для таблиц, описывающих сущности, должен быть простой естественный ключ, который идентифицирует отдельные экземпляры так же, как и те, которые люди делают. Если у объекта нет надежных идентификаторов для одного из объектов, я прибегу к суррогатной клавише.
Для таблиц, описывающих отношения, я использую составной ключ, где каждый компонент ссылается на сущность, которая участвует в связи, и, следовательно, на строку в таблице сущностей. Опять же, производительность при использовании составного ключа обычно минимальна.
Как отмечали другие, термин "первичный ключ" немного вводит в заблуждение. В модели реляционных данных термин, который используется, - это "ключи-кандидаты". Для одной таблицы может быть несколько ключей-кандидатов. Логично, что каждый из них так же хорош, как и другой. Выбор одного из них как "первичного" и создание всех ссылок через этот ключ - это просто выбор, который может сделать дизайнер.
Это сложный вопрос, осознал ли вы это или нет. Возможно, это относится к разделу этого FAQ по StackOverflow.
Какие вопросы я не могу задать здесь?
Избегайте задавать вопросы, которые являются субъективными, аргументативными или требуют расширенного обсуждения. Это место для вопросов, на которые можно ответить!
Это обсуждалось много лет и будет продолжаться в течение многих лет. Единственные намеки на консенсус, которые я видел, это то, что ответы несколько предсказуемы в зависимости от того, спрашиваете ли вы OO-парня (GUID - это единственный путь!), Модельер данных (естественные ключи - единственный способ пойти!), или ориентированный на производительность DBA (INT - единственный путь!).