естественный ключ против суррогатного ключа внешний ключ innodb - PullRequest
Новая
       21

естественный ключ против суррогатного ключа внешний ключ innodb

12 голосов
/ 01 ноября 2011

Вопрос:

У меня есть 2 таблицы: 

Product
id INT
name VARCHAR(64)
something TEXT
else INT
entirely BOOL

и 

Ingredient
id INT
name VARCHAR(64)
description TEXT

Теперь у меня также есть таблица ссылок 

Products_Ingredients
product_id INT
ingredient_id INT

для моего отношения ко многим.

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

Скажите, у меня есть продукт: Paint Thinner Supreme с ингредиентом: Butylonitrotetrocycline

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

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

Каково ваше мнение?

Ответы [ 2 ]

17 голосов
/ 02 ноября 2011

Мнения не имеют значения, когда вы можете измерять.

Я реализовал это на PostgreSQL, используя как естественные ключи, так и суррогаты.Я использовал 300 000 всего продуктов, 180 ингредиентов и заполнил две таблицы «ингредиенты продуктов» с 3-17 ингредиентами на продукт для 100 000 случайно выбранных продуктов (1053462 строк).

Выбор всех ингредиентов для одного продукта с использованиеместественные ключи вернулись за 0,067 мс.Используя суррогаты, 0.199мс.

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

Таким образом, естественные ключи были примерно в 2–3 раза быстрее для этого набора данных.

Естественные ключи не требуют каких-либо объединений для возврата этих данных.Суррогатные ключи требуют двух объединений.

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

Когда я проектировал базу данных для операционной базы данных моего работодателя, я построил испытательный стенд с таблицами, созданными на основе естественных ключей, и таблицами, созданными на основе числовых идентификаторов.Обе эти схемы содержат более 13 миллионов строк компьютерных образцов данных.В некоторых случаях запросы к схеме идентификатора числа опережали схему естественного ключа на 50%.(Таким образом, сложный запрос, который занимал 20 секунд с номерами идентификаторов, занимал 30 секунд с естественными ключами.) Но 80% тестовых запросов имели более высокую производительность SELECT по сравнению со схемой естественного ключа.И иногда это было ошеломительно быстрее - разница от 30 до 1.

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

3 голосов
/ 02 ноября 2011

В этом случае я бы предпочел суррогатные ключи, потому что

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