Что такое unique key

Уникальный ключ в условиях распределенной БД

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

Какие требования (кроме уникальности) могут предъявляться к ключам?

Какие существуют способы генерации уникальных ключей?

Генерация ID на стороне приложения (UUID и т.п.)

С UUID все относительно просто — берем библиотеку и генерируем ключи на стороне приложения. UUID широко используется во многих системах. Значение формируется таким образом, что коллизии невозможны.

Минусы:
• Длина стандартного UUID 128 бит (которые, на самом деле, часто хочется хранить прямо в виде строки шестнадцатеричных цифр, а это уже 32 байта)
• Как правило, UUID не дает естественной сортировки ключей

Отдельный сервис, для генерации ключей

Такой вариант используют, например, Flick и Twitter.

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

Автоинкремент на стороне базы данных по диапазонам значений

Весь диапазон значений делится на поддиапазоны и каждый шард (узел кластера) отвечает за свой диапазон, например:

Минусы:
• БД должна поддерживать автоинкремент (не применимо для многих NoSQL-хранилищ)
естественная сортировка невозможна
• Клиент «не знает» ключ до вставки объекта. Чтобы узнать ключ нужно делать отдельный запрос.
• Практически невозможно увеличить количество узлов кластера

Aвтоинкремент от Instagram

Об этом решении рассказано в техническом блоге команды Instgram (photo sharing application).

Они используют 64-битный ключ, который формируется на стороне БД (PostgreSQL) и состоит из битовых полей

где
— CUSTOM TIMESTAMP (41 бита) — время в миллисекундах от 2011-01-01 00:00:00
— SHARD ID (13 бит) — идентификатор логического раздела (число шардов больше, чем число физических узлов)
— AUTO (10 бит) — последовательность (sequence), уникальная в пределах логического раздела (шарда)

Плюсы (по сравнению с автоинкрементом по диапазонам):
• Автоматическая хронологическая сортировка

А вы какие варианты знаете и используете?

Источник

Первичный ключ, внешний ключ и уникальный ключ при использовании выделенного пула SQL в Azure Synapse Analytics

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

Ограничения таблиц

Выделенный пул SQL поддерживает следующие ограничениях на уровне таблиц:

Синтаксис см. в описании команд ALTER TABLE и CREATE TABLE.

Ограничение FOREIGN KEY в выделенном пуле SQL не поддерживается.

Remarks

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

После создания таблицы с ограничением PRIMARY KEY или UNIQUE в выделенном пуле SQL пользователям нужно убедиться, что все значения в этих столбцах уникальные. Нарушение этого требования приведет к тому, что результат запроса будут неточным. В этом примере показано, как запрос может вернуть неточный результат, если столбец первичного ключа или уникального ограничения содержит повторяющиеся значения.

Примеры

Создайте таблицу в выделенном пуле SQL с первичным ключом:

Создайте таблицу в выделенном пуле SQL с ограничением UNIQUE:

Дальнейшие действия

После создания таблиц для выделенного пула SQL переходите к загрузке данных в таблицу. Дополнительные сведения см. в статье Загрузка данных в выделенный пул SQL.

Источник

Как использовать уникальные индексы в MySQL

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

В данном примере, колонка ‘id’ является первичным ключом. Если при выполнении INSERT запроса явно не задать значение для этого поля, то оно будет увеличено автоматом (AUTO_INCREMENT).

Представьте что вы добавили следующие данные:

Далее выполняем следующий INSERT запрос:

MySQL не вставит новые данные в таблицу, потому как в ней уже есть запись с id, равным 1. Если же мы опустим значение для поля id, то оно будет посчитано автоматически:

После выполнения запроса, таблица будет выглядеть так:

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

Прекрасно… однако номер телефона у записей 1 и 4 абсолютно идентичны. Что если мы хотим сделать поле phone тоже уникальным?

Уникальные индексы

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

В нашем случае укажем что в таблице не может быть записи с одинаковыми данными в полях country, area, number и extension. Делаем это следующим образом:

Название индекса (‘ix_phone’) указывать не обязательно. С тем же успехом, можем удалить таблицу и создать её заново:

Уникальные индексы существуют и в других СУБД, но SQL синтаксис для их создания может отличаться.

Теперь давайте попробуем вставить запись, подставив уже существующие данные:

В результате, MySQL выдаст следующую ошибку:

Таким образом в вашей таблице никогда не появится несколько записей с одинаковыми данными.

MySQL и NULL

Есть в MySQL одна особенность. Каждый отдельный NULL является уникальным значением; именно поэтому сравнение нужно осуществлять не так value = NULL, а так value IS NULL. К тому же, это так же распространяется и для значений в уникальных индексах.

Учитывая эту особенность, следующий INSERT запрос мы можем выполнять сколько угодно раз, и каждый раз в поле extension будет вставлен NULL (он считается уникальным для каждой отдельной записи):

Да, это полностью рушит логику нашего уникального индекса.

Решение: убедитесь, что все поля в индексе не могут содержать NULL.

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

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: http://www.sitepoint.com/use-unique-indexes-mysql-databases/
Перевел: Станислав Протасевич
Урок создан: 11 Января 2014
Просмотров: 47190
Правила перепечатки

5 последних уроков рубрики «Разное»

Как выбрать хороший хостинг для своего сайта?

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

Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

Разработка веб-сайтов с помощью онлайн платформы Wrike

20 ресурсов для прототипирования

Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Топ 10 бесплатных хостингов

Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

Источник

Руководство по проектированию реляционных баз данных (4-6 часть из 15) [перевод]

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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

В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

Первичные ключи в повседневной жизни

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

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

Что характеризует первичный ключ? Характеристики первичного ключа.

Первичный ключ служит для идентификации записей.

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

Первичный ключ уникален.

Первичный ключ всегда имеет уникальное значение. Представьте, что его значение не уникально. Тогда его бы нельзя было использовать для того, чтобы идентифицировать данные в таблице. Это значит, что какое-либо значение первичного ключа может встретиться в столбце, который выбран в качестве первичного ключа, только один раз. РСУБД устроены так, что не позволят вам вставить дубликаты в поле первичного ключа, получите ошибку.
Еще один пример. Представьте, что у вас есть таблица с полями first_name и last_name и есть две записи:

| first_name | last_name |
| vasya |pupkin |
| vasya |pupkin |

Т.е. есть два Васи. Вы хотите выбрать из таблицы какого-то конкретного Васю. Как это сделать? Записи ничем друг от друга не отличаются. Вот здесь и помогает первичный ключ. Добавляем столбец id (классический вариант синтетического первичного ключа) и…

Id | first_name | last_name |
1 | vasya |pupkin |
2 | vasya |pupkin |

Теперь каждый Вася уникален.

Типы первичных ключей.

Обычно первичный ключ – числовое значение. Но он также может быть и любым другим типом данных. Не является обычной практикой использование строки в качестве первичного ключа (строка – фрагмент текста), но теоретически и практически это возможно.
Составные первичные ключи.
Часто первичный ключ состоит из одного поля, но он может быть и комбинацией нескольких столбцов, например, двух (трех, четырех…). Но вы помните, что первичный ключ всегда уникален, а значит нужно, чтобы комбинация n-го количества полей, в данном случае 2-х, была уникальна. Подробнее об этом расскажу позднее.

Поле первичного ключа часто, но не всегда, обрабатывается самой базой данных. Вы можете, условно говоря, сказать базе данных, чтобы она сама автоматически присваивала уникальное числовое значение каждой записи при ее создании. База данных, обычно, начинает нумерацию с 1 и увеличивает это число для каждой записи на одну единицу. Такой первичный ключ называется автоинкрементным или автонумерованным. Использование автоинкрементных ключей – хороший способ для задания уникальных первичных ключей. Классическое название такого ключа – суррогатный первичный ключ [Как и упоминалось выше. – прим. перев.]. Такой ключ не содержит полезной информации, относящейся к сущности (объекту), информация о которой хранится в таблице, поэтому он и называется суррогатным.

5. СВЯЗЫВАНИЕ ТАБЛИЦ С ПОМОЩЬЮ ВНЕШНИХ КЛЮЧЕЙ

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

Один-ко-многим.

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

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

Какую информацию мы будем хранить? Решаем первый вопрос.

Для начала мы определимся какую информацию о заказах и о клиентах мы будем хранить. Чтобы это сделать мы должны задать себе вопрос: “Какие единичные блоки информации относятся к клиентам, а какие единичные блоки информации относятся к заказам?”

Проектируем таблицу клиентов.

Заказы действительно принадлежат клиентам, но заказ – это это не минимальный блок информации, который относится к клиентам (т.е. этот блок можно разбить на более мелкие: дата заказа, адрес доставки заказа и пр., к примеру).
Поля ниже – это минимальные блоки информации, которые относятся к клиентам:

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

Создание таблицы в SQLyog. Обратите внимание, что выбран флажок первичного ключа (PK) для поля customer_id. Поле customer_id является первичным ключом. Также выбран флажок Auto Incr, что означает, что база данных будет автоматически подставлять уникальное числовое значение, которое, начиная с нуля, будет каждый раз увеличиваться на одну единицу.

Проектируем таблицу заказов.
Какие минимальные блоки информации, необходимые нам, относятся к заказу?

Ниже – пример таблицы в SQLyog.

Проект таблицы. Поле customer является ссылкой (внешним ключом) для поля customer_id в таблице клиентов.

Эти две таблицы (клиентов и заказов) связаны потому, что поле customer в таблице заказов ссылается на первичный ключ (customer_id) таблицы клиентов. Такая связь называется связью по внешнему ключу. Вы должны представлять себе внешний ключ как простую копию (копию значения) первичного ключа другой таблицы. В нашем случае значение поля customer_id из таблицы клиентов копируется в таблицу заказов при вставке каждой записи. Таким образом, у нас каждый заказ привязан к клиенту. И заказов у каждого клиента может быть много, как и говорилось выше.

Создание связи по внешнему ключу.

Вы можете задаться вопросом: “Каким образом я могу убедиться или как я могу увидеть, что поле customer в таблице заказов ссылается на поле customer_id в таблице клиентов”. Ответ прост – вы не можете сделать этого потому, что я еще не показал вам как создать связь.
Ниже – окно SQLyog с окном, которое я использовал для создания связи между таблицами.

Создание связи по внешнему ключу между таблицами заказов и клиентов.

В окне выше вы можете видеть, как поле customer таблицы заказов слева связывается с первичным ключом (customer_id) таблицы клиентов справа.

Теперь, когда вы посмотрите на данные, которые могли бы быть в таблицах, вы увидите, что две таблицы связаны.

Заказы связаны с клиентами через поле customer, которое ссылается на таблицу клиентов.

На изображении вы видите, что клиент mary поместила три заказа, клиент pablo поместил один, а клиент john – ни одного.
Вы можете спросить: “А что же именно заказали все эти люди?” Это хороший вопрос. Вы возможно ожидали увидеть заказанные товары в таблице заказов. Но это плохой пример проектирования. Как бы вы поместили множественные продукты в единственную запись? Товары – это отдельные сущности, которые должны храниться в отдельной таблице. И связь между таблицами заказов и товаров будет являться связью один-ко-многим. Я расскажу об этом далее.

6. СОЗДАНИЕ ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ

Ранее вы узнали как записи из разных таблиц связываются друг с другом в реляционных базах данных. Перед созданием и связыванием таблиц важно, чтобы вы подумали о сущностях, которые существуют в вашей системе (для которой вы создаете базу данных) и решили каким образом эти сущности бы связывались друг с другом. В проектировании баз данных сущности и их отношения обычно предоставляются в диаграмме сущность-связь (англ. entity-relationship diagram, ERD). Данная диаграмма является результатом процесса проектирования базы данных.

Сущности.

Вы можете задаться вопросом, что же такое сущность. Нуу… это “вещь” в системе. Там. Моя Мама всегда хотела, чтобы я стал учителем потому, что я очень хорошо объясняю различные вещи.

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

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

Заказ оплачивается клиентом… это интересно. Мы собираемся создавать отдельную таблицу для платежей в базе данных нашего интернет-магазина? Возможно. Но разве платежи – это минимальный блок информации, который относится к заказам? Это тоже возможно.

Если вы не уверены, то просто подумайте о том, какую информацию о платежах вы хотите хранить. Возможно, вы захотите хранить метод платежа или дату платежа. Но это все еще минимальные блоки информации, которые могли бы относиться к заказу. Можно изменить формулировки. Метод платежа — метод платежа заказа. Дата платежа – дата платежа заказа. Таким образом, я не вижу необходимости выносить платежи в отдельную таблицу, хотя концептуально вы бы могли выделить платежи как сущность, т.к. вы могли бы рассматривать платежи как контейнер информации (метод платежа, дата платежа).

Давайте не будет слишком академичными.

Как вы видите, есть разница между сущностью и непосредственно таблицей в базе данных, т.е. это не одно и то же. Специалисты отрасли информационных технологий могут быть ОЧЕНЬ академичными и педантичными в этом вопросе. Я не такой специалист. Эта разница зависит от вашей точки зрения на ваши данные, вашу информацию. Если вы смотрите на моделирование данных с точки зрения программного обеспечения, то вы можете прийти к множеству сущностей, которые нельзя будет перенести напрямую в базу данных. В данном руководстве мы смотрим на данные строго с точки зрения баз данных и в нашем маленьком мире сущность – это таблица.

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

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

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

Связи.

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

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

Источник

Разница между ключом, основным ключом, уникальным ключом и индексом в MySQL

ОТВЕТЫ

Ответ 1

Также обратите внимание, что столбцы, определенные как первичные ключи или уникальные ключи, автоматически индексируются в MySQL.

Ответ 2

KEY и INDEX являются синонимами.

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

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

Ответ 3

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

Ответ 4

PRIMARY KEY И UNIQUE KEY похожи, кроме того, что у него разные функции. Первичный ключ делает строку таблицы уникальной (т.е. Не может быть 2 строки с одним и тем же ключом). В таблице базы данных может быть только 1 первичный ключ.

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

INDEX также создает уникальность. MySQL (пример) создаст таблицу индексирования для индексированного столбца. Таким образом, легче получить значение строки таблицы, когда запрос запрашивается в столбце с индексированной таблицей. Недостатком является то, что если вы выполняете много обновлений/удалений/создания, MySQL должен управлять таблицами индексирования (и это может быть узким местом производительности).

Надеюсь, что это поможет.

Ответ 5

Уникальные ключи: столбцы, в которых нет двух строк, похожих

Первичный ключ: сбор минимального количества столбцов, который может однозначно идентифицировать каждую строку в таблице (т.е. две строки не похожи во всех столбцах, составляющих первичный ключ). В таблице может быть несколько первичных ключей. Если существует уникальный ключ, то это первичный ключ (а не «первичный ключ» ) в таблице. Если не существует уникального ключа, то для идентификации строки, такой как (first_name, last_name, father_name, mother_name), в некоторых таблицах может использоваться более одного значения столбца.

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

Ответ 6

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

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

Разница между основным ключом и уникальным ограничением ключа

1. В таблице может быть только один первичный ключ, но более одного уникального ключа

2. Первичный ключ не разрешает нули, где в качестве уникального ключа допускается один null

Ответ 7

Ответ 8

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

Ответ 9

Уникальный ключ:

Основной ключ

Источник