Почему я должен создавать столбец идентификатора, когда я могу использовать другие в качестве ключевых полей? [Дубликат]

  

Возможный дубликат:
Зачем использовать int в качестве первичного ключа таблицы поиска?

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

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

Я видел, что люди используют поля целочисленного идентификатора для всего, и никто не судит этот метод, потому что

  • он выглядит «эффективным»
  • используется числовое поле, и оно выглядит более холодным из-за его размера в строка в памяти

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

  • Если ваше поле ID равно 32 битам, это эквивалентно 4 символам ASCII уже.
  • Если ваше поле идентификатора 64 бит целое число, это строка 8 символов , поэтому на самом деле не сохраняет значительную часть памяти (подразумевается здесь память, используемая при сравнении. дополнительный столбец id уже добавляется в используемую память (как на HDD, так и на RAM))
  • Дополнительное поле идентификатора удваивает стоимость индексации , потому что вы также     индексируйте уникальное поле, которое вы можете использовать в качестве первичного ключа.
  • Вы делаете дополнительные соединения , если вам нужны данные, которые вы могли бы использовать в качестве ключевого поля, например, если вы сохранили уникальный идентификатор пользователя в одном блоге, чтобы показать имя автора, вы делаете запрос на объединение, если ваше ключевое поле было именем автора, вам не нужно присоединяться, потому что вы храните соответствующие данные в таблице сообщений блога. внешний ключ поле со значимыми данными уменьшает необходимость в подзапросе или присоединяется

введите описание изображения здесь>> </p>

<ul>
<li> Создание дополнительного поля id добавляет к загрузке памяти, это не
замену уникального строкового поля, вы не заменяете
char-varchar с целым числом, вы добавляете <strong> extra
столбца </strong> и создает <strong> дополнительный поток данных </strong>. поэтому любое сравнение
хранилище данных должно быть выполнено между «строкой» и «int + string». добавление
целое число id не сохраняет пробел. </li>
</ul>
<p> с другой стороны </p>

<ul>
<li> назначение данных первичного ключа, которое получает значение от пользовательского ввода,  может быть
проблематичным , потому что люди могут, например, ввести социальное обеспечение
номер неправильный, и фактическое лицо, которое хочет зарегистрироваться, не будет
способный регистрироваться из-за уникальной политики. Это может быть
обходятся путем добавления дополнительной цифры или цифр к исходному номеру. </li>
</ul>
<p> Дополнительные ресурсы: </p>

<ol>
<li> <a href= Сравнение естественных ключей Суррогата vc

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

40 голосов | спросил Uğur Gümüşhan 22 22011vEurope/Moscow11bEurope/MoscowTue, 22 Nov 2011 23:56:28 +0400 2011, 23:56:28

7 ответов


37

1 - Это быстрее. A JOIN для целого числа намного быстрее, чем JOIN в поле строки или комбинации полей. Лучше сравнивать целые числа, чем строки.

2 - Это проще. Гораздо проще сопоставлять отношения на основе одного числового поля, чем на комбинации других полей различных типов данных.

3 - Независимо от данных. Если вы сопоставляете идентификатор ID, вам не нужно беспокоиться об изменении отношения. Если вы совпадаете с именем, что вы будете делать, если их имя изменится (т. Е. Брак)? Если вы соглашаетесь на адрес, что делать, если кто-то движется?

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

ИЗМЕНИТЬ

К конкретным моментам, которые вы только что добавили:

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

3 - Если вы кластер в поле ID, то он не добавляет ничего лишнего. Это SAVES пространство, поскольку вы используете более эффективный идентификатор строки.

4 - И тогда, когда этот человек меняет свое имя пользователя, ваши ссылки все ломаются.

5 - Ты действительно не знаешь, о чем говоришь. Вам нужно хранить данные, это правильно, но гораздо эффективнее индексировать и JOIN в int, чем в комбинации других полей.

ответил JNK 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 00:04:08 +0400 2011, 00:04:08
20

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

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

Даже (или даже особенно!), когда идентификатор «кажется» уникальным, это может оказаться неверным. Например: номер социального страхования в США. Он должен быть уникальным для человека, не так ли? Конечно, но что делать, если некоторые записи были введены с SSN, которые в прошлом были омрачены пользователями? Теперь могут возникнуть проблемы с конфликтами с новыми действительными числами, которые вводятся для новых записей. Следует отметить, что первичные ключи также никогда не должны отображаться, поскольку они приводят к предположениям пользователей о них, и они также не подходят для лучшей модели безопасности для URL-адресов веб-сайтов.
Всегда считайте, будет ли пользователь добавлять этот URL-адрес и ожидать, что он будет работать в будущем?

Итак, люди узнали:

Не используйте «суррогатный ключ» (например, SSN) в качестве первичного ключа, когда суррогат имеет «любую» коммерческую ценность или значение.
Вместо этого используйте первичный ключ, который является уникальным и не выводится из данных приложения.

ответил Michael Durrant 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 02:49:14 +0400 2011, 02:49:14
11

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

Но если у вас есть таблица, которую вы используете для отношения «многие-ко-многим», она не нужна. Допустим, у вас есть следующие две таблицы:

Новости таблицы целое число id название varchar текст элемента

Табличные теги целое число id имя varchar

Для каждого элемента в новостях вы хотите добавить один или несколько тегов, чтобы создать таблицу:

Таблица news_tags news_id integer tags_id integer

В этом случае, действительно, не нужно создавать дополнительный столбец id, потому что он вам вообще не понадобится.

ответил Michiel van Vaardegem 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 00:02:23 +0400 2011, 00:02:23
4

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

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

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

В естественном мире вещи не определяются уникальным идентификатором, а их отношением к другим объектам. Поле id действительно является артефактом реляционных баз данных. Это является основой всей задачи сопоставления объектных отношений (ORM).

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

ответил hafichuk 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 00:11:45 +0400 2011, 00:11:45
1

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

  • Если вам когда-либо понадобится копировать таблицу, которая никогда не имела и не нуждалась в первичном ключе, тогда вам придется ее создать. если у вас есть этот столбец идентификатора на месте. = easy as pie

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

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

  • Если у вас нет столбца create_date /entry_date, и вам нужно будет проверить данные в том порядке, в котором они были введены. Наличие столбца идентификатора в качестве идентификатора делает это возможным.

  • Идентификатор может также действовать как внешний ключ.

ответил 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 00:05:32 +0400 2011, 00:05:32
0

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

Также часто бывает более эффективным поиск по цифровому ключу.

ответил 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 00:00:49 +0400 2011, 00:00:49
-1

Поскольку идентификатор используется для идентификации всего. Возьмите пользователя в качестве примера - поиск пользователя по имени пользователя медленнее, чем Integer (ID)

ответил 23 32011vEurope/Moscow11bEurope/MoscowWed, 23 Nov 2011 00:00:00 +0400 2011, 00:00:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132