Как вам ваши первичные ключи?

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

Я поклонник автоинкремента в качестве первичного ключа. В глубине души я знаю, что это отговорка, но она позволяет легко сортировать данные по времени их добавления (ORDER BY ID DESC, f'r instance).

3 колонки звучат ужасно жестко для человеческого анализа.

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

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

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

Лично мне нравятся int с автоинкрементом.

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

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

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

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

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

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

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

There should be atleast 3 columns that make up the primary key.

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

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

Int/ BigInt which autoincrement are good enough primary keys.

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

Guids.period.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне нравится автоматическое приращение целых чисел, потому что это помогает с удобочитаемостью. Например, я могу сказать: «Взгляните на запись 129383», и кому-то довольно легко найти ее. С GUID это сделать практически невозможно.

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

• Не слишком ли сложное определение первичного ключа? Избегает ли он введения ненужной сложности ради следования «лучшим практикам»?
• Есть ли лучший возможный первичный ключ, который потребовал бы меньше накладных расходов для обработки базы данных (например, INTEGER против VARCHAR и т. д.)?
• Я АБСОЛЮТНО уверен, что инвариант уникальности и определенности моего первичного ключа не изменится?

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

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

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

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

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

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

• Суррогатные ключи полезны, когда никакой другой атрибут или набор атрибутов в таблице не подходит для однозначной идентификации строк.
• По возможности предпочтительнее использовать естественные ключи, чтобы сделать таблицу более удобочитаемой. Естественные ключи также позволяют внешнему ключу в зависимой таблице содержать реальное значение вместо суррогатного идентификатора. Например. когда вам нужно сохранить state (Калифорния, Техас, Нью-Йорк), вы также можете использовать естественный ключ char(2) вместо int.
• При необходимости используйте составные первичные ключи. Не добавляйте суррогатный ключ «id» без необходимости, когда существует совершенно хороший составной ключ (это особенно верно в таблицах «многие ко многим»). Обязанность использовать ключ из трех столбцов в каждой таблице - абсолютная чепуха.
• GUID - это решение, когда вам нужно сохранить уникальность на нескольких сайтах. Они также удобны, если вам нужно, чтобы значения в первичном ключе были уникальными, но не упорядоченными или последовательными.
• INT против BIGINT: нечасто, что таблица требует представляет собой 64-битный диапазон для первичных ключей, но с увеличением доступности 64-битного оборудования это не должно быть обузой и дает больше уверенности в том, что вы не переполнитесь. INT, конечно, меньше, поэтому, если пространство ограничено, это может дать небольшое преимущество.

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

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

Кроме того, наличие любого ключа служит нескольким часто несовместимым целям.

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

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

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

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

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

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

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

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

Теперь для выбора суррогатного ключа я придерживаюсь столбцов идентификаторов (я работаю в основном в MS SQL Server). GUID слишком велики, и Microsoft рекомендует против использовать их в качестве PK. Если у вас несколько серверов, все, что вам нужно сделать, это сделать приращение 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

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

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

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

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

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

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

1 номер $ 40 MTL
2 Другое 3-й номер2 $ 150 TRV

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

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

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

RE GUID's

Остерегайтесь, действительно ли это будет действительно ДЕЙСТВИТЕЛЬНО большая база данных В САМОМ ДЕЛЕ, большая нагрузка и быстрый доступ.

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

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

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

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

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

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

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

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

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

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

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

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

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

... и нет разумной причины не:

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

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

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

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

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

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

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

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

Мне нравится мой уникальный.