Что я должен рассмотреть при выборе типа данных для моего первичного ключа?
Просто попробуйте sudo pip3.6 install --upgrade pip. Если это не работает, переустановите pip.
16 ответов
Извините, что сделал это, но я нашел, что ответы, которые я дал связанным вопросам (можно проверить это и это) могли относиться к этому. Я изменил их немного...
Вы найдете много сообщений, занимающихся этой проблемой, и каждый выбор, который Вы сделаете, имеет свои за и против. Аргументы в пользу них обычно обращаются к теории реляционной базы данных и производительности базы данных.
На этом предмете моя точка очень проста: суррогатные первичные ключи ВСЕГДА работают, в то время как Естественные ключи НЕ МОГЛИ БЫ ВСЕГДА работать на днях, и это по нескольким причинам: поле, слишком короткое, управляет изменение и т.д.
К этой точке Вы предположили здесь, что я - в основном член uniqueIdentifier/surrogate команды первичного ключа, и даже если я ценю и понимаю аргументы, такие как те представленные здесь, я все еще ищу случай, где "естественный" ключ лучше, чем суррогат...
В дополнение к этому один из самых важных, но всегда аргументов, о которых забывают, в пользу этого основного правила связан для кодирования нормализации и производительности:
каждый раз я составляю таблицу, буду я терять время
- определяя его первичный ключ и его физические характеристики (тип, размер)
- при запоминании этих характеристик каждый раз я хочу обратиться к нему в своем коде?
- объяснение моего выбора PK другим разработчикам в команде?
Мой ответ не ко всем этим вопросам:
- Я не имею ни одной лишней секунды, пытаясь определить "лучший Естественный Первичный ключ", когда суррогатная опция дает мне пуленепробиваемое решение.
- Я не хочу помнить, что Первичный ключ моего Table_whatever является 10 длинными строками символов, когда я пишу код.
- Я не хочу терять свое время, согласовывая Естественную Длину ключа: "хорошо, если Вам нужно 10, почему Вы не берете 12, чтобы быть на безопасной стороне?". Это "на безопасной стороне" аргумент действительно раздражает меня: Если Вы хотите остаться на безопасной стороне, это означает, что Вы действительно недалеко от небезопасной стороны! Выберите суррогат: это является пуленепробиваемым!
Таким образом, я работал в течение прошлых пяти лет с очень простым правилом: каждой таблице (позволяют нам назвать это 'myTable') назвали его первое поле 'id_MyTable' который имеет uniqueIdentifier тип. Даже если эта таблица поддерживает "many-many" отношение, где полевая комбинация предлагает очень приемлемый Первичный ключ, я предпочитаю создавать это 'id_myManyToManyTable' причем поле является uniqueIdentifier, только для придерживаний правила, и потому что, наконец, это не причиняет боль.
Главное преимущество состоит в том, что Вы не должны больше заботиться об использовании Первичного ключа и/или Внешнего ключа в рамках Вашего кода. После того как у Вас есть имя таблицы, Вы знаете имя PK и тип. После того как Вы знаете, какие ссылки реализованы в Вашей модели данных, Вы будете знать название доступных внешних ключей в таблице.
И если Вы все еще хотите иметь свой "Естественный Ключ" где-нибудь в Вашей таблице, я советую Вам создавать его после стандартной модели такой как
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed
.....
Где id_ является префиксом для первичного ключа, и code_ используется для "естественного" индексируемого поля. Некоторые утверждали бы, что code_ поле должно быть установлено как уникальное. Это верно, и этим можно легко управлять или через DDL или через внешний код. Обратите внимание, что много "естественных" ключей вычисляются (номера счетов-фактур), таким образом, они уже сгенерированы через код
Я не уверен, что мое правило является лучшим. Но это - очень эффективное! Если бы все применяли его, то мы, например, избежали бы, чтобы время потеряло ответ на этот вид вопроса!
Каждый раз, когда возможно, попытайтесь использовать первичный ключ, который является естественным ключом. Например, если бы у меня была таблица, где я регистрировал одну запись каждый день, logdate был бы хорошим первичным ключом. Иначе, если нет никакого естественного ключа, просто используйте интервал. Если Вы думаете, что будете использовать больше чем 2 миллиарда строк, использовать bigint. Некоторым людям нравится использовать GUID, который работает хорошо, поскольку они уникальны, и у Вас никогда не будет заканчиваться пространство. Однако они напрасно длинны, и трудно вводить, если Вы просто делаете специальные запросы.
Я обычно всегда использую целое число, но вот интересная перспектива.
https://blog.codinghorror.com/primary-keys-ids-versus-guids/
Я обычно иду с первичным ключом столбца GUID для всех таблиц (rowguid в mssql). Что могло быть естественными ключами, я делаю ограничения на уникальность данных. Типичным примером был бы идентификационный номер продукта, который пользователь должен составить и удостовериться, что это уникально. Если мне нужна последовательность, как в счете я создаю таблицу для хранения lastnumber и хранимой процедуры для обеспечения сериализированного доступа. Или Последовательность в Oracle :-) Я ненавижу образец "номера социального страхования" за естественные ключи, поскольку то число никогда не будет alway доступный в процессе регистрации. Приведение к потребности в плане генерировать фиктивные числа.
Используйте естественные ключи, когда им можно будет доверять. Некоторым источникам естественных ключей нельзя доверять. Несколько лет назад, Управление социального обеспечения раньше иногда портило присваивание того же SSN двум различным людям. Theyv'e, вероятно, зафиксировал это к настоящему времени.
Можно, вероятно, доверять VINs для механизмов и ISBNs для книг (но не для брошюр, которые не могут иметь ISBN).
При использовании естественных ключей естественный ключ определит тип данных.
Если Вы не можете доверять никаким естественным ключам, создайте синтетический ключ. Я предпочитаю целые числа с этой целью. Оставьте достаточно комнаты для разумного расширения.
Большой фактор - то, сколько данных Вы собираетесь хранить. Я работаю на компанию веб-аналитики, и у нас есть ЗАГРУЗКИ данных. Таким образом, первичный ключ GUID на нашей таблице просмотров страниц уничтожил бы нас, из-за размера.
Эмпирическое правило: Для высокой производительности необходимо смочь сохранить весь индекс в памяти. Гуиды могли легко повредить это!
Все это зависит.
a) Прекрасны Вы имеющие уникальные последовательные числовые числа как Ваш первичный ключ? Если да, то, выбирая UniqueIdentifier, поскольку Ваш первичный ключ будет достаточен. b) Если Ваша бизнес-потребность такова, что у Вас должна быть альфа числовой первичный ключ, то Вы добрались для движения для varchar или nvarchar.
Это эти две опции, о которых я мог думать.
Для "естественного" ключа, независимо от того, что тип данных удовлетворяет столбцу (столбцам). Искусственные (суррогатные) ключи обычно являются целыми числами.
Я неравнодушен к использованию сгенерированного целочисленного ключа. Если Вы ожидаете, что база данных станет очень большой, можно пойти с bigint.
Некоторым людям нравится использовать гуиды. Про там - то, что можно объединить несколько экземпляров базы данных, не изменяя ключей, но довод "против" - то, что производительность может быть затронута.
Числа, которые имеют значение в реальном мире, обычно являются плохой идеей, потому что время от времени реальный мир изменяет правила о том, как те числа используются, в особенности для разрешения дубликатов, и затем у Вас есть реальная путаница на Ваших руках.
Не используйте числовой тип с плавающей точкой, так как числа с плавающей точкой не могут быть правильно сравнены для равенства.
- Где Вы генерируете его? Постепенное увеличение числа не соответствует хорошо для ключей, сгенерированных клиентом.
- Вы хотите информационно-зависимый или независимый ключ (иногда, Вы могли использовать идентификатор от бизнес-данных, не может сказать, полезно ли это всегда или не)?
- Как хорошо это может ввести быть индексированным Вашим DB?
Я использовал uniqueidentifiers (GUID) или целые числа постепенного увеличения до сих пор.
Аплодисменты Matthias
Если Вы не имеете ультраудобный естественный ключ в наличии, всегда используйте синтетический продукт (иначе суррогат) ключ числового типа. Даже если Вы действительно имеете естественный ключ в наличии, Вы могли бы хотеть рассмотреть использование синтетического ключа так или иначе и размещения дополнительного уникального индекса на Вашем естественном ключе. Рассмотрите то, что произошло с базами данных более высокого редактора, которые использовали номера социального страхования в качестве PKs, когда измененный федеральный закон, затраты на переход на синтетические ключи был огромен.
Кроме того, я должен не согласиться с практикой именования каждого первичного ключа то же, например, "идентификатор". Это делает запросы тяжелее для понимания, не легче. Первичные ключи нужно назвать в честь таблицы. Например, сотрудник employee_id, филиал affiliate_id, пользователь user_id, и так далее.
В большинстве случаев я использую первичный ключ интервала идентификационных данных, если сценарий не требует большой репликации, в этом случае я могу выбрать GUID.
Я (почти) никогда не использовал значимые ключи.
При использовании числового ключа удостоверьтесь, что тип данных собирается быть достаточно большим для содержания количества строк, до которых Вы могли бы ожидать, что таблица вырастет.
При использовании гуида, делает дополнительное пространство, должен был сохранить гуид, должен быть рассмотрен? Будет кодирование против гуида PKs быть болью для разработчиков или пользователей приложения.
При использовании составных ключей действительно ли Вы уверены, что объединенные столбцы всегда будут уникальны?
Мне действительно не нравится то, что они преподают в школе, которая использует 'естественный ключ' (например, ISBN на bookdatabase) или даже имеет первичный ключ, составленный от 2 или больше полей. Я никогда не делал бы этого. Таким образом, вот мой небольшой совет:
- Всегда имейте один специальный столбец в каждой таблице для Вашего первичного ключа.
- У них всех должны быть то же название столбца через все таблицы, т.е. "идентификатор" или "GUID"
- Используйте GUID, когда Вы можете (если Вам не нужна производительность), иначе увеличивая INTs
Править:
Хорошо, я думаю, что должен объяснить свой выбор немного.
Наличие специального столбца namend то же через всю таблицу для Вас, которых первичный ключ, просто делает Ваши SQL-операторы большим количеством более легких для построения и легче для кого-то еще (кто не мог бы быть знаком с расположением базы данных), легче понять. Особенно, когда Вы делаете много СОЕДИНЕНИЙ и подобных вещей. Вы не должны будете искать то, что является первичным ключом для определенной таблицы, Вы уже знаете, потому что это - то же везде.
GUID по сравнению с INTs не делают действительно вопросов так очень большую часть времени. Если Вы не поразите ограничение производительности GUID или выполнения слияний базы данных, у Вас не будет главных проблем с одной или другим. НО существует причина, я предпочитаю GUID. Глобальная уникальность GUID могла бы всегда пригождаться однажды. Возможно, Вы не видите потребность в нем теперь, но вещи как, синхронизируя части базы данных к ноутбуку / сотовый телефон или даже находя datarecords, не будучи должен знать, в какой таблице они находятся, яркие примеры преимуществ, которые могут обеспечить GUID. Целое число только определяет запись в контексте одной таблицы, тогда как GUID определяет запись везде.