Использование идентификатора в базах данных

Question

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

Кроме того, для чего используется поле длины / значения?Новое в этом.

спасибо большое!

Answer 1

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

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

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

Answer 2

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

Что касается первого вопроса: вам только необходимо использовать суррогатный ключ , если у вас нет действительного естественного ключа для использования в качестве основного ключ на столе. Все вменяемые системы баз данных поддерживают предложение «ON UPDATE CASCADE », что означает, что если вы используете естественный ключ, который может измениться, изменение будет распространено на все , которое объявлено для ссылки на него. . Конечно, если ваша система баз данных не поддерживает внешние ключи , тогда лучше всего использовать суррогатный ключ, хотя бы для того, чтобы обойти отсутствие функциональности в системе базы данных (а суррогатные ключи сделают ваш База данных проще для проверки согласованности в свете этого факта). Тем не менее, если вы разрабатываете приложение, которое предъявляет требования к высокому времени безотказной работы и высокой надежности, выберите реализацию базы данных, которая получает правильные внешние ключи, или вы, скорее всего, обнаружите, что ошибки целостности данных будут обнаружены в конце разработки (или даже в обслуживании) ) и вам придется написать утилиты, которые будут проверять ваши данные на согласованность в различных режимах сбоя.

По второму вопросу: если вы используете суррогатный ключ, особенно если вы работаете с недостатком системы базы данных, вы должны всегда обращаться с ним, как если бы он был неизменным и глобально уникальное . ВСЕГДА. Это поможет во многих ситуациях позже: компании могут объединяться (и разделяться), базы данных могут объединяться (и разделяться), и может произойти около миллиона других ситуаций, которые не ожидаются, когда база данных Предназначен для создания проблем, если суррогатные ключи не являются глобально уникальными. Поскольку суррогатные ключи совсем не связаны с данными, которые они хранят (они не имеют никакого отношения к другим полям таблицы, кроме искусственных, которые вы ему наделили), лучше всего так. По этим причинам, когда я должен использовать суррогатный ключ, я использую UUID (который по сути является 128-разрядным целым числом, но не инкрементным). Теперь вам не нужно беспокоиться о перенумерации номеров записей и ссылок, когда происходят непредвиденные события. (Да, это замедляет работу, особенно если ваш сервер работает на 32-битной платформе. Но если вам нужно справиться с большей нагрузкой, лучше распределите нагрузку - не жертвуйте целостностью ради скорости, ever , когда вы работаете с важными данными!)

Answer 3

Отношения между таблицами.

Неэффективно иметь отношение к username или email адресу, потому что это string, и сравнение этих значений занимает гораздо больше времени, а индексы больше, оптимальным решением является добавление ID, например первичный ключ , для связи с другими таблицами, например userid.

Answer 4

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

А использование поля идентичности позволит вам делать такие вещи, как Comments (id, user_id), а не Comments (id, username, email) ...

Answer 5

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

Назначение длины - ограничение ввода данных. Например, varchar длиной 10 позволит вводить только 10 символов. Значение для целей по умолчанию. Если вы вставите новую строку без объявления этого поля, оно будет автоматически заполнено значением, если оно установлено.