Sql для чего нужен primary key
SQL Ключевое слово PRIMARY KEY
SQL PRIMARY KEY
Команда PRIMARY KEY ограничение однозначно идентифицирует каждую запись в таблице.
Таблица может иметь только один первичный ключ, который может состоять из одного или нескольких полей.
SQL PRIMARY KEY в CREATE TABLE
Следующий SQL создает первичный ключ в столбце «ID» при создании таблицы «Persons»:
SQL Server / Oracle / MS Access:
Чтобы разрешить именование ограничения PRIMARY KEY и определить ограничение PRIMARY KEY для нескольких столбцов, используйте следующий синтаксис SQL:
MySQL / SQL Server / Oracle / MS Access:
Примечание: В приведенном выше примере существует только один первичный ключ (PK_Person). Однако значение первичного ключа состоит из TWO COLUMNS (ID + LastName).
SQL PRIMARY KEY в ALTER TABLE
Чтобы создать ограничение первичного ключа для столбца «ID», когда таблица уже создана, используйте следующий SQL:
MySQL / SQL Server / Oracle / MS Access:
Чтобы разрешить именование ограничения первичного ключа и определить ограничение первичного ключа для нескольких столбцов, используйте следующий синтаксис SQL:
MySQL / SQL Server / Oracle / MS Access:
Примечание: Если вы используете инструкцию ALTER TABLE для добавления первичного ключа, то столбец(ы) первичного ключа уже должен быть объявлен не содержащим нулевых значений (при первом создании таблицы).
Отбросить ограничение первичного ключа
Чтобы удалить ограничение первичного ключа, используйте следующий SQL:
Создание первичных ключей
Определить первичный ключ в SQL Server можно с помощью среды SQL Server Management Studio или Transact-SQL. Создание первичного ключа автоматически приводит к созданию соответствующего уникального кластеризованного индекса (или некластеризованного при наличии такого указания).
Перед началом
Ограничения
В таблице возможно наличие только одного ограничения по первичному ключу.
Все столбцы с ограничением PRIMARY KEY должны иметь признак NOT NULL. Если допустимость значения NULL не указана, то для всех столбцов c ограничением PRIMARY KEY устанавливается признак NOT NULL.
безопасность
Permissions
Создание новой таблицы с первичным ключом требует разрешения CREATE TABLE в базе данных и разрешения ALTER на схему, в которой создается таблица.
Создание первичного ключа в существующей таблице требует разрешения ALTER на таблицу.
Использование среды SQL Server Management Studio
Создание первичного ключа
Чтобы переопределить первичный ключ, необходимо удалить все связи с существующим первичным ключом и только после этого создавать новый первичный ключ. Появится сообщение, предупреждающее об автоматическом удалении в ходе процесса всех существующих связей.
Ключевой столбец-источник идентифицируется символом первичного ключа в соответствующем селекторе строк.
Если первичный ключ состоит более чем из одного столбца, то в одном столбце могут встречаться дублирующиеся значения, но все сочетания значений изо всех столбцов первичного ключа должны быть уникальными.
При определении составного ключа порядок столбцов в первичном ключе совпадает с порядком столбцов, показанным в таблице. Однако после создания первичного ключа порядок столбцов можно изменить. Дополнительные сведения см. в разделе Изменение первичных ключей.
Использование Transact-SQL
Создание первичного ключа в существующей таблице
В следующем примере создается первичный ключ для столбца TransactionID в базе данных AdventureWorks.
Создание первичного ключа в новой таблице
В следующем примере создается таблица и определяется первичный ключ для столбца TransactionID в базе данных AdventureWorks.
Создание первичного ключа с кластеризованным индексом в новой таблице
В следующем примере создается таблица и определяется первичный ключ для столбца CustomerID и кластеризованного индекса для TransactionID в базе данных AdventureWorks.
jtest.ru
HTML, CSS, JavaScript, JQuery, PHP, MySQL
SQL для начинающих. Часть 2
Представляю Вашему вниманию вольный перевод статьи SQL for Beginners Part 2
Для каждого веб-разработчика важно уметь взаимодействовать с базами данных. Во второй части мы продолжаем изучение языка SQL и применяем свои навыки к СУБД MySQL. Мы познакомимся с индексами, типами данных и более сложными запросами.
Что вам нужно
Обратитесь, пожалуйста, к разделу «Что вам нужно» первой части, которая находится здесь.
Если Вы хотите выполнять приведенные примеры на своем сервере, сделайте следующее:
Индексы
Индексы (или ключи) обычно используются для повышения скорости выполнения операторов, которые выбирают данные (такие как SELECT) из таблиц.
Они являются важной частью хорошей архитектуры баз данных, сложно их отнести к «оптимизации». Обычно индексы добавляются изначально, но могут быть добавлены позднее с помощью запроса ALTER TABLE.
Основные доводы в пользу индексации столбцов базы данных:
Первичный ключ (PRIMARY KEY)
Почти у всех таблиц есть первичный ключ, обычно это целое число с опцией автоинкремента (AUTO_INCREMET).
Если Вы вспомните, в первой части, мы создали поле user_id в таблице пользователей (users) и он был первичным ключом. В веб-приложениях, мы можем обратиться ко всем пользователям по их номеру id.
Значения, хранящиеся в столбце первичный ключей, должны быть уникальными. В каждой таблице может быть не более одного столбца с первичными ключами.
Давайте рассмотрим простой запрос, который создает таблицу для хранения списка штатов США:
Можно записать его так:
Уникальный ключ (UNIQUE)
Поскольку мы предполагаем, что имя штата уникально, нам надо немного изменить предыдущий запрос:
По-умолчанию индекс будет назван также как и столбец. Если Вы хотите добавить произвольное имя для индекса, используйте такой запрос:
Теперь индекс называется «state_name», а не «name».
Индекс (INDEX)
Допустим мы хотим добавить столбец для хранения года, в котором каждый штат вошел в состав США.
Я добавил столбец «join_year» и проиндексировал его. Этот тип индекса не накладывает ограничение на уникальность.
Вы можете использовать KEY вместо INDEX.
Подробнее о производительности
Добавление индекса снижает производительность запросов INSERT и UPDATE. Потому что каждый раз при вставке новых данных в таблицу, данные индекса тоже обновляются, что требует выполнения дополнительной работы. Увеличение производительности для запросов SELECT обычно перевешивают эти недостатки. Однако не надо добавлять индексы к каждому столбцу таблицы, не подумав о том какие запросы будут выполняться.
Пример таблицы
Перед тем как идти дальше, я хотел бы создать таблицу с некоторыми данными.
Это будет список штатов с датами их присоединения (дата ратификации штатом Конституции США и принятия его в Союз) и текущей численностью населения. Вы можете скопировать этот листинг в консоль MySQL:
GROUP BY: Группировка данных
Предложение GROUP BY группирует результирующий набор данных. Пример:
Итак, что произошло? В таблице у нас 50 строк, а запрос вернул только 34. Так произошло, потому что результат сгруппирован по столбцу «join_year». Другими словами, мы видим только уникальные позиции столбца join_year. Некоторые штаты имеют одно и тоже значение join_year, поэтому мы получили менее 50 строк.
Например, присутствует только одно значение с 1787 годом, хотя в эту группу входят 3 штата:
Вот эти три штата, но только название штата Delaware показано после выполнения запроса с группировкой. На самом деле мы могли бы увидеть название любого из трех штатов. Тогда в чем же смысл использования предложении GROUP BY?
Оно было бы бесполезно без использования совместно с агрегирующими функциями, например с COUNT(). Давайте посмотрим что делает эта функция и как с ее помощью извлечь полезные данные.
COUNT(*): Подсчет строк
Это, пожалуй, наиболее часто используемая функция в запросах совместно с предложением GROUP BY. Она возвращает количество строк в каждой группе.
Например, мы можем использовать ее для подсчета количества штатов для каждого join_year:
Группировка всего
Если вы используете GROUP BY с агрегирующей функцией, но не уточняете предложение GROUP BY, то результат будет помещен в одну группу.
Количество строк во всей таблице:
Количество строк удовлетворяющие условию WHERE:
MIN(), MAX() и AVG()
Эти функции возвращают минимальное, максимальное и среднее значения:
GROUP_CONCAT()
Эта функция объединяет все значения внутри группы в одну строку с разделителем.
В первом запросе с GROUP BY только один штат для каждого года. Используя данную функцию, мы можем видеть все имена в каждой группе:
Вы можете использовать эту функцию для сложения численных значений.
IF() & CASE: Управление потоком выполнения
Как и в других языках программирования, в SQL есть конструкции для управления потоком выполнения.
Вот более практический пример использования функции SUM():
Результат выполнения запроса:
CASE (Выбор)
CASE работает подобно условию switch-case в других языках программирования.
Предположим, что мы хотим разделить штаты на три возможные категории.
Как Вы видите, мы можем применить GROUP BY для значений, возвращаемых после условия CASE. Вот что произошло:
HAVING: Условие для скрытых полей
Условие HAVING применяется для «скрытых» полей, таких как результат, возвращаемый агрегирующей функцией. Обычно оно используется совместно с GROUP BY.
Для примера давайте рассмотрим запрос, который мы использовали для подсчета штатов по году их присоединения:
Теперь, скажем, что нас интересуют только строки с количеством больше 1. Мы не можем использовать условие WHERE для этого:
На помощь приходит HAVING:
Помните, что такая возможность доступна не во всех СУБД.
Подзапросы
Можно использовать результат одного запроса в другом.
В этом примере мы получим штат с наибольшим населением:
Внутренний запрос возвращает наибольшую численность населения из всех штатов. Во внешнем запросе снова происходит поиск в таблице этого значения.
Наверное вы подумаете, что это плохой пример, и я с вами соглашусь. Такой запрос можно записать эффективнее так:
Хотя результаты и одинаковы, есть большое различие в этих запросах. Следующий пример это демонстрирует более наглядно.
В этом примере мы получим штат, который был присоединен к Союзу последним:
Возможно Вы захотите использовать несколько резульатов, возвращаемых внутренним запросом.
Следущий запрос находит года, в которых было присоединено к Союзу сразу несколько штатов, и возвращает их список:
Подробнее о подзапросах
Подзапросы могуть быть очень сложными, поэтому я не буду слишком углубляться в них в этой статье. Если Вы хотите почитать о них более подробно, обратитесь к руководству по MySQL.
Очень часто подзапросы ведут к значительному снижению производительности, поэтому используйте их с осторожностью.
UNION: Совмещение данных
Используя запрос UNION, можно объединять результаты нескольких напросов SELECT.
В этом примере объединяются штаты, название которых начинается с буквы «N», со штатами с большим населением:
Обратите внимание, что штат New York принадлежит крупным и начинается с буквы «N». Однако в списке он встречается один раз, т.к. дубликаты удаляются автоматически.
Так же прелесть запросов UNION заключается в том, что их можно использовать для объединения запросов к разным таблицам.
Например, у нас есть таблицы employees (сотрудники), managers (менеджеры) и customers (клиенты). В каждой таблице есть поле с адресом электронной почты. Если мы хотим получить все E-mail адреса в одном запросе, то можем поступить следующим образом:
Выполнив этот запрос, мы получим почтовые адреса всех сотрудников и менеджеров, и только тех клиентов, которые подписаны на рассылку.
INSERT Продолжение
Мы уже говорили о запросе INSERT в предыдущей статье. После того как мы рассмотрели индексы, мы можем поговорить о дополнительных возможностях запросов INSERT.
Это наиболее часто используемое условие. Сначала запрос пытается выполнить INSERT, и если запрос терпит неудачу в следствии дублирования первичного (PRIMARY KEY) или уникального (UNIQUE KEY) ключа, то выполняется запрос UPDATE.
Давайте сначала создадим тестовую таблицу.
Это таблица для хранения продуктов. Поле «stock» хранит количество продуктов доступных на складе.
Теперь попробуем вставить уже существующее значение в таблицу и посмотрим что произойдет.
Мы получили ошибку.
Допустим, мы получили новую хлебопекарню и хотим обновить базу данных, но не знаем есть ли уже запись в базе данных. Мы можем сначала проверить существование записи, а потом выполнить другой запрос для вставки. Или можно выполнить все в одном простом запросе:
REPLACE INTO
Работает также как и INSERT, но с одной важной особенностью. Если запись уже существует, то она удаляется, а потом выполняется запрос INSERT, при этом мы не получим никаких сообщений об ошибке.
Обратите внимание, т.к. вставляется совершенно новая строка, поле автоинкремента увеличивается на единицу.
INSERT IGNORE
Это способ предотвращения появления ошибки о дублировании, прежде всего для того, чтобы не останавливать выполнение приложения. Может понадобится вставить новую строку без вывода каких-либо ошибок, если даже произошло дублирование.
Нет никаких ошибок и обновленных строк.
Типы данных
Каждый столбец в таблице должен быть определенного типа. Мы уже использовали типы INT, VARCHAR и DATE, но не останавливались на них подробно. Также мы рассмотрим еще несколько типов данных.
Начнем с числовых типов данных. Я разделяю из на две группы: Целые и дробные.
Целые
Столбец с типом целые может хранить только натуральные числа (без десятичной точки). По-умолчанию они могут быть положительными или отрицательными. Если выбрана опция UNSIGNED, то могут храниться только положительные числа.
MySQL поддерживает 5 типов целых чисел разных размеров и диапазонов:
Дробные числовые типы данных
Эти типы могут хранить дробные числа: FLOAT, DOUBLE и DECIMAL.
FLOAT занимает 4 байта, DOUBLE занимает 8 байт и аналогичен предыдущему. DOUBLE более точный.
Например, DECIMAL(13,4) имеет 9 знаков до запятой и 4 после.
Строковые типы данных
По названию можно догадаться, что в них можно хранить строки.
CHAR(N) может хранить N символов и имеет фиксированную величину. Например, CHAR(50) должен всегда содержать 50 символов в каждой строке во всем столбце. Максимально возможное значениен 255 символов
Разновидности типа TEXT больше подходят для длинных строк. TEXT имеет ограничение в 65535 символов, MEDIUMTEXT в 16.7 миллионов, и LONGTEXT в 4.3 миллиарда символов. MySQL обычно хранит их в отдельных хранилищах на сервере, для того что бы главное хранилище было по возможности меньше и быстрее.
Тип DATE (Дата)
Тип DATE хранит даты и показывает их в формате «YYYY-MM-DD», но не хранит информацию о времени. Имеет диапазон от 1001-01-01 до 9999-12-31.
Тип DATETIME содержит дату и время и имеет формат «YYYY-MM-DD HH:MM:SS». Имеет диапазон от «1000-01-01 00:00:00» до «9999-12-31 23:59:59». Занимает 8 байт.
TIMESTAMP работает как DATETIME с некоторыми отличаями. Он занимает только 4 байта и имеет диапазон «1970-01-01 00:00:01» UTC до «2038-01-19 03:14:07» UTC. Например, он не очень подходит для хранения дат рождения.
Тип TIME хранит только время, а YEAR только год.
Другое
Другие типы данных, поддерживаемые MySQL. Посмотреть их список можно здесь. Так же обратите внимание на размеры хранимых данных каждого типа.
Заключение
Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.
Часть 11.3: Первичные ключи в базах данных SQLite: PRIMARY KEY. Ограничение первичного ключа
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Мы разобрались с ограничениями уровня столбца и узнали, какие возможности есть у СУБД для поддержания целостности данных на уровне таблицы. Теперь давайте более подробно поговорим про ограничения уровня таблицы и первым ограничение, которое мы рассмотрим, будет ограничение первичного ключа или просто PRIMARY KEY.
Первичные ключи в базах данных SQLite: PRIMARY KEY. Ограничение первичного ключа.
В теории баз данных ключ или ключевой атрибут — это столбец, который позволяет однозначно идентифицировать таблицу в базе данных. На практике, ни одна СУБД в мире не знает о таком столбце и не знает теории баз данных. На практике есть первичный ключ, который является правилом, которое SQLite ни когда не нарушит. SQLite будет следить всегда за тем, чтобы в столбце PRIMARY KEY были всегда уникальные и вечные значения.
В этой записи мы рассмотрим ограничения первичного ключа в базах данных SQLite в теории и на практике, так же узнаем, почему первичный ключ это не только правило базы данных, но еще и индекс, а так же поговорим о том, как реализовать составной первичный ключ для таблицы базы данных SQLite3
Первичный ключ, как ограничение уровня таблицы в базах данных SQLite. PRIMARY KEY в SQLIte3
Первичный ключ, это не только ключевой атрибут, который идентифицирует таблицу в базе данных и даже не только обязательное условие второй нормальной формы, а, соответственно, и третьей нормальной формы. Первичный ключ или столбец PRIMARY KEY – это ограничение уровня таблицы для любой реляционной СУБД.
Ограничение уровня таблицы – это правило, которое никогда не должна нарушать ни одна СУБД и не должна никому давать это делать. Первичный ключ или PRIMARY KEY в базах данных SQLite – это столбец, значения которого должны быть уникальными и вечными, и что бы не произошло, что бы не случилось, SQLite никогда не нарушит правило уникальности и вечности первичного ключа.
Если мы задали первичный ключ для таблицы при помощи PRIMARY KEY, то, во-первых, мы сами должны заботиться об уникальности и вечности, во-вторых, SQLite будет делать это за нас. Если вы видите, что значения в столбце повторяющиеся и SQLite не дает вам их добавить, то, вероятнее всего, вы ошиблись при проектировании базы данных и назначили не тот столбец в качестве PRIMARY KEY.
Когда мы создаем первичный ключ, как ограничение таблицы, то вместо PRIMARY KEY мы вправе использовать конструкцию UNIQUE KEY, SQLite это позволяет и никаких проблем с таким подходом у вас не будет.
Помимо всего прочего, первичный ключ в базе данных SQLite, вернее столбец, который мы назначили, как PRIMARY KEY, является еще и индексом таблицы. Благодаря индексам таблицы операция выборки данных из базы данных при помощи команды SELECT происходит значительно быстрее, но место на диске база данных начинает занимать больше
Вывод: первичный ключ в базах данных SQLite3 или PRIMARY KEY – это правила, которые нельзя нарушать: правила уникальности и вечности значений столбца PRIMARY KEY. Так же первичный ключ является индексом таблицы в базе данных SQLite. Столбец, который объявлен, как PRIMARY KEY – это индекс, которому мы можем даже дать имя.
Пример использования первичного ключа в SQLite. Пример PRIMARY KEY в SQLite
Мы разобрались в теории, что собой представляет первичный ключ в реляционных базах данных, а также выяснили, что для создания первичного ключа необходимо использовать конструкцию PRIMARY KEY, тогда SQLite3 поймет, что данный столбец является первичным ключом, а его значения должны быть уникальными и вечными.
Давайте теперь на практике посмотрим, как первичный ключ может обеспечить целостность данных в базе данных и посмотрим, как в SQLite можно объявить столбец с ограничением PRIMARY KEY.
Руководство по SQL. Констрейнт PRIMARY_KEY.
Для таблицы первичный ключ (Primary Key) – это поле, которое являетс ядентификатором для каждой отдельной записи в таблице базы данных (далее – БД). Первичный клдюч обязательно должен быть NOT NULL.
Таблица может иметь только один первичный ключ, который может состоять как из одного, так и из несколькх полей. Когда первичный ключ таблицы использует несколько полей, он называется композитным.
Если таблица имеет первичный ключ, прикреплённый к любому полю, то мы не можем иметь две записи с одинкаовым значением данного поля. Другими словами, в каждой таблице первичный ключ – это уникальное значение.
Предположим, что у нас есть таблица developers, в которой поле ID является первичным ключом. В этом случае, наша таблица будет иметь следующий вид:
Для того, чтобы определить первичный ключ в уже существующей талице в RDBMS MySQL мы должны применить следующую команду:
Стоит отметить, что если мы хотим указать первичный ключ в уже существующей таблице, необходимо, чтобы указзаное нами поле уже имело констрейнт NOT NULL.
Для того, чтобы опредлеить композитный первичный ключ в той же RDBMS мы должны использовать команду, указанную ниже:
Для создания констрейнта PRIMARY KEY для полей ID и NAMES в уже существующей таблице для RDBMS MySQL, мы должны использовать такую команду:
Для удаление констрейнта PRIMARY KEY в той же RDBMS испольуется следующая команда:
На этом мы заканчиваем изучение констрейнта PRIMARY KEY.