Как избежать ошибок в первичном ключе

Question

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

    CREATE TABLE customer(
    name
    first_lastname
    street
    ZIP_code
    mobile_phone
    telephone
    email
    gender
    birthdate
    nationality);

По желанию я хотел добавить idcustomer в качестве auto_incrementно я не уверен, что это будет отличная идея.

Answer 1

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

Answer 2

Самый безопасный подход - создать столбец PK с именем id в каждой таблице.Не будь героем, просто иди за неподписанным bigint.Переполнение PK, однако маловероятно, не является проблемой, которую вы хотите.

Вы можете использовать: id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY

Или заменить средние биты ключевым словом SERIAL, которое является псевдонимом для BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE

Имейте в виду, что AUTO_INCREMENT может вызывать проблемы, если вы используете репликацию на основе операторов. Репликация на основе операторов является значением по умолчанию до 5.7.6.

Использование синтетического ключа отделяет функции объекта, который вы моделируете, от уникального идентификатора этого объекта, что удобно, если вам нужно изменить схему.Изменение MySQL PK стоит дорого.Это также гарантирует, что у вас будет уникальный, ненулевой столбец для ссылки на внешние ключи.Кроме того, некоторые ORM ожидают столбец id PK - если вы к этому относитесь.

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

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

Answer 3

Есть несколько желательных свойств ПЕРВИЧНОГО КЛЮЧА (некоторые из них довольно очевидны, но мы перечислим их)

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

---

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

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

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

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

 CREATE TABLE mytable 
 ( id                INT NOT NULL AUTO_INCREMENT PRIMARY KEY  COMMENT 'PK'
 , cust_email        VARCHAR(255) NOT NULL                    COMMENT 'UX1'
 , cust_name_title
 , cust_name_first
 , cust_name_last
 , cust_name_suffix
 , cust_addr_street
 , cust_addr_line2
 , cust_addr_city
 , cust_addr_state
 , cust_addr_postal_code
 , UNIQUE KEY customer_UX1 (cust_email) 
 )

Обратите внимание, что использование AUTO_INCREMENT не требование.Это функция, которую многие считают полезной и простой в использовании.(Есть некоторые подробности об AUTO_INCREMENT, которые делают его менее совершенной функцией с точки зрения PRIMARY KEY.)

---

ВАЖНО

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

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

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

Answer 4

Первичный ключ - это столбец или набор столбцов, которые однозначно идентифицируют строки в таблице.Имея это в виду, вы можете создать любой столбец (столбцы), которые уникально идентифицируют строки customer в качестве первичного ключа.Вы можете использовать номер телефона или комбинацию имени, фамилии и номера телефона в качестве первичного ключа.Но более приемлемый способ - добавить дополнительный столбец, возможно, с именем idcustomer, как вы думали, или customer_id, или просто id, который обязательно должен быть уникальным для каждого клиента, и сделать его первичным ключом;сделать этот целочисленный столбец auto_increment хорошая идея.

Answer 5

Я думал добавить idcustomer как auto_increment, но я не уверен, что это будет отличная идея.

Это действительно хорошая идея.

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

Таким образом, создание гарантированного уникального первичного ключа обычно является хорошим дизайном.Жаргон для этого типа ключа - суррогатный первичный ключ.Большинство систем СУБД, включая MySQL, предоставляют для этого автоинкрементные числа.

Вы можете выбрать одно из двух соглашений для присвоения имени id значению.Один должен назвать это id.Другой - назвать его customer_id (имя таблицы с добавленным _id).Второй поможет вам разобраться, когда вы начнете использовать эти значения в других таблицах для установления отношений.

Например, у вас может быть таблица продаж.Эта таблица может иметь следующие столбцы:

sales_id      autoincrementing pk
customer_id   the id of the customer to whom the sale was made. (foreign key)
item_sold     description of the item
list_price
discount
net_price

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

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

 SELECT customer.name, customer.first_lastname,
        COUNT(sales.sales_id) number_of_sales,
        SUM(sales.net_price) revenue
   FROM customer
   JOIN sales ON customer.customer_id = sales.customer_id
  GROUP BY customer.customer_id, customer.name, customer.first_lastname

Здесь sales Сущность имеет отношение многие-к-одному с customer сущностью .Это достигается наличием атрибута customer_id в каждой строке sales, указывающей на клиента.

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

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

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