Лучше создавать связи между связанными столбцами БД, используя "Индекс" или используя запрос?

Question

Мне интересно, что было бы лучшим способом создания соединений между связанными столбцами БД - в запросе или с помощью Index? Я знаю, что основная проблема с использованием Index это скорость исполнения, и я не верю, что это проблема здесь.

Каждый столбец в таблице представляет различные атрибуты продукта, и многие из столбцов напрямую связаны с несколькими другими столбцами (обычно 2–3 столбцами) одним из следующих способов:

1. Альтернативные типы данных для одного и того же атрибута (например, отображаемое имя цвета + hex# или имя изображения + имя файла.png + значение alt). Значения в этих столбцах представляют одну и ту же информацию, но в другом формате, поэтому существует прямая корреляция между значениями, но сами значения не идентичны.

2. Подмножества, используемые для классификации значений в столбце. Одни и те же значения существуют более чем в одном столбце (с отношениями родитель / потомок или одноуровневый). Например, столбец "Все цвета" подразделяется на 5 столбцов, обозначающих различные типы цветов (т. Е. Темный, светлый, яркий и т. Д.), И большинство этих групп далее подразделяются на 3 категории (ранжированные по степени темноты и т. Д.)..). Цвет ВМФ находится в 3 колонках - "Цвета все", "Темные цвета" и "Тона драгоценного камня".

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

В настоящее время я использую mySql с инструкциями извлечения PDO (но я могу переключать базы данных в течение следующих 12 месяцев)

Answer 1

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

Когда таблица создается, столбцы определяются, и некоторые из этих столбцов могут быть определены как FOREIGN KEYS, относящиеся к другим столбцам в другой таблице. Связь между таблицами полезна только для целей ссылочной целостности (если движок ее поддерживает). Это также полезно для документирования, и некоторые разработчики запросов используют их, чтобы угадать объединения в запросе.

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

Таким образом, FOREIGN KEY определяют отношения между таблицами, запросы объединяют связанные таблицы, а индексы ускоряют операции объединения, фильтрации, группировки и сортировки в запросе.

Редактировать: таблица используется для представления типа объекта. Таким образом, у нас может быть таблица цветов с двумя атрибутами: colors(color_name, color_value). Color_value может быть шестнадцатеричной строкой или целочисленным представлением. В принципе, у нас не было бы столбца для цветового кода в формате rgb(x,y,z), потому что это всегда можно вычислить из первого.

У нас была бы другая таблица для хранения списка изображений. Однако нет никакой связи между таблицей цветов и таблицей изображений.

Редактировать 2: Второй тип обычно представлен двумя таблицами. Первая таблица хранит типичное иерархическое отношение, а вторая таблица сообщает, какими классами помечен каждый цвет. Итак, ваша реляционная модель для приведенных вами примеров будет выглядеть так:

colors(colorid, color_name, color_value)
color_classes(classid, classname, parentid)
colors_classes(colorid, classid)

e.g.,
(colorid, color_name, color_value) - colors
(1,       'Navy',     'xxx')

(classid, classname,    parentid) - color_classes
(1,      'All colors',    0)
(2,      'Dark colors',   1)
(3,      'Light colors',  1)
(4,      'Jewel Tones',   2) -- assuming Jewel Tones is a subdivision of Dark Colors

(colorid, classid) - colors_classes
(1,       4)       -- assuming Jewel Tones is a subdivision of Dark Colors

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

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