Ставить ли primary key на связывающую таблицу?

Question

[Dark_Dante]

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

Нужно ли ставить primary_key в таблице brands_state на поля id_brand и id_group (id_group и id_brand integer конечно, там на схеме чуть неправильно)?

Answer 1

[d-stream]

Без глубокого понимания стоит задать себе непреложное правило "у каждой таблицы должен быть primary key". В дальнейшем, когда-нибудь можно будет достичь нирваны ситуации когда pk не должно быть.

Comments

[Dark_Dante]

А в случае моей таблицы brands_state целых два ключа?

[Дмитрий Энтелис]

Dark_Dante, у вас один ключ из 2х полей

[d-stream]

Dark_Dante, primary - он всегда один, но может быть составным

[Dark_Dante]

Дмитрий Энтелис, d-stream, Ага, спасибо, я кажется начал понимать как это работает.

[d-stream]

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

[Dark_Dante]

d-stream, А зачем тогда нужны таблицы без PK? Смысл их существования?

[d-stream]

Dark_Dante,

А зачем тогда нужны таблицы без PK? Смысл их существования?

я еще не достиг такого уровня дзена

[Дмитрий Энтелис]

Dark_Dante, хочется ответить старой шуткой про кота который лижет яйца.

Answer 2

[egor_nullptr]

Обязательно.

Comments

[Dark_Dante]

А разве не foreign key?

[Константин]

Почему?

[Dark_Dante]

Константин, хз. Говорю же, я смутно эту систему понимаю. primary_key по моему разумению ставится на уникальное значение, которое может выступать однозначным указателем. В таблице brands_state может быть два одинаковых значения id_brand, например когда бренд принадлежит двум группам. Или два бренда одной группе. То есть в поле id_brand (id_group) значение неуникально. А foreign_key указывает, (опять же, как я это понимаю), что значение поля id_brand может принимать весь диапазон значений brands.id и в случае удаления/изменения brands.id выполняется какое то действие с таблицей brands_state, обеспечивающее целостность данных.

[Melkij]

primary key - определяет уникальную строку. Про то, что он может быть из одного поля речи нет. Если уникальность задают два поля - то и PK будет состоять из двух полей.

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

[Dark_Dante]

Melkij, Спасибо, кажется я начинаю понимать :)

Answer 3

[Denis Holub]

Так и не понял зачем все рекомендуют на таблицу brands_state ставить primary key, если это таблица связей.
Там два foreign keys.

Я бы не ставил (да и не ставлю на такие таблицы связей pk, они в них не нужны).

UP:
Если pk это попытка сделать связь уникальной (чтобы дубли не порождались), то это вопрос к логике приложения, который бездумно дублирует строки, состоящие из двух полей внешних ключей, а не к constraint'ам SQL.

Comments

[Dark_Dante]

Может быть это как то с быстродействием связано?

[Denis Holub]

Dark_Dante, вам там нужны foreign keys для целостности данных.
Ставить 2 foreign key дополнительно еще как и составной primary key учитывая что кроме них там вообще ничего больше не будет (там 2 поля), это вообще для чего? Для уникальности?
На скорость влиять не будет в таблице связей.

[Dark_Dante]

На самом деле ситуация такая. Есть семь таблиц, которые объединены через одну, связывающую. Примерно как на схемке. Связывающая таблица состоит из, примерно, 147 млн записей. Выбирается все это дело SELECTOM с INNER JOIN'aми. И вот все это дело несчадно тормозит. Индексы на всех полях в этой связывающей таблице стоят. Вот бьюсь, чтобы ускорить выборку...

[Denis Holub]

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

Индексы выбраны ли правильные или наоборот они замедляют работу (EXPLAIN смотреть надо, пробовать разные варианты).

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

[Dark_Dante]

Denis Holub, А как узнать ускоряет ли индекс или замедляет работу базы? По Explain'у все поля eq_ref, кроме двух - они ref - на оба идет WHERE. В общем я туп в этом деле. Я как в тумане от непонимания структуры данных и принципах работы БД, хожу, спотыкаюсь, набиваю шишки :)
Насчет актуальности... в принципе... можно разбить на несколько таблиц по актуальности (ну или частоте обращений). Идея хорошая, я над ней подумаю =)

[Константин]

Dark_Dante, вот этой информации про 150 млн записей, индексирование всех полей, тормозящий запрос и не хватает в вашем исходном вопросе. И здесь исследование начинают обычно с проверки планов выполнения запросов. Обычно здесь-то и выясняются причины проблем. Без планов запросов можно много теорий наплодить. Например, в случае двух таблиц данных и одной таблицы связей, как на рисунке, всё может тормозить, если все 150 млн брендов сидят в одной группе, и вы пытаетесь запросом вытащить все бренды из этой группы. Даже если всё индексировано - тут индексы не помогли бы.
Может, вам вообще нужно в сторону фасетного поиска смотреть.

[Denis Holub]

@skssxf
да меня тоже подробности поразили (начиналось то с таблицы связи 2х таблиц), а тут 147млн и индексы.

Про фасетный поиск сам впервые слышу, тут немного объясняется (или гуглить дальше). Это для Dark_Dante

[Dark_Dante]

Denis Holub, Ну на простом примере более понятно :) Смысл то тот же остался, только масштабы другие :) Вот например узнал что примари кей можно на несколько полей ставить. А я на одно ставил, а mysql ругался типа значение неуникальное. Я аж всю голову сломал.