Оптимальная структура таблиц MySQL для быстрого поиска

Question

Для таблицы со 100% чтением (без записи), какая структура лучше и почему?

[В моей таблице много столбцов, но я привел здесь пример с 4 столбцами для простоты]

Вариант 1: одна таблица с несколькими столбцами

ID | Length   | Width    | Height
-----------------------------------------
1  | 10       | 20       | 30
2  | 100      | 200      | 300

Вариант 2: две таблицы;один хранит заголовки столбцов, а другие хранят значения

Таблица 1:

ID | Object_ID | Attribute_ID | Attribute_Value
------------------------------------------
1  | 1         | 1            | 10
2  | 1         | 2            | 20
3  | 1         | 3            | 30
4  | 2         | 1            | 100
5  | 2         | 2            | 200
6  | 2         | 3            | 300

Таблица 2:

ID | Name
-------------------
1  | Length
2  | Width
3  | Height

Answer 1

Ваш второй вариант - недостаточно оптимизированная реализация анти-паттерна EAV:

Модель Entity-Attribute-Value

Почему это плохо, уже обсуждалосьдо смерти на этом сайте и в других местах.

Вы получите намного лучшие результаты с первого раза.

Answer 2

Я предвосхищу это, сказав, что я новичок в SQL и таблицах базы данных; это, однако, не означает, что я не знаю своих основ.

Если ваш пример сильно не упрощен, вам действительно следует использовать первый пример. Мало того, что это будет быстрее и проще запрашивать, но это просто имеет больше смысла.

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

Как правило, вы открываете новую таблицу и ссылаетесь на нее, как если бы у вас был другой объект, существующий отдельно, относящийся к вашему объекту с отношением один-ко-многим.

Вот пример (фактически из моей базы данных на сервере O'Reilly) с использованием записей в блоге и комментариев к записям в блоге:

mysql> select * from blog_entries;
+----+--------------+-------------+---------------------+
| id | poster       | post        | timestamp           |
+----+--------------+-------------+---------------------+
|  1 | lunchmeat317 | blah blah   | 0000-00-00 00:00:00 |
|  2 | Yongho Shin  | yadda yadda | 0000-00-00 00:00:00 |
+----+--------------+-------------+---------------------+
2 rows in set (0.00 sec)

mysql> select id, blog_id, poster, post, timestamp from blog_comments;
+----+---------+--------------+----------------+---------------------+
| id | blog_id | poster       | post           | timestamp           |
+----+---------+--------------+----------------+---------------------+
|  1 |       1 | lunchmeat317 | humina humina  | 0000-00-00 00:00:00 |
|  2 |       1 | Joe Blow     | huh?           | 0000-00-00 00:00:00 |
|  3 |       2 | lunchmeat317 | yakk yakk yakk | 0000-00-00 00:00:00 |
|  4 |       2 | Yongho Shin  | lol            | 0000-00-00 00:00:00 |
+----+---------+--------------+----------------+---------------------+
4 rows in set (0.00 sec)

mysql>

Думайте об этом с логической точки зрения; нет никакой причины искусственно вводить сложность в этот дизайн, когда он не должен быть там. В вашем примере длина, ширина и высота на самом деле не являются отдельными объектами, и все они связаны с размерами объекта, который вы описываете в строке таблицы. Кроме того, ширина и высота длины имеют только одно значение в данный момент времени.

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

Удачи.

Редактировать: Я только что понял, что ваш вопрос был конкретно о производительности. Это немного более подробно, возможно, основано на движке БД, который вы используете? Однако, как правило, я бы предположил, что запрос к таблице без каких-либо объединений будет немного быстрее, учитывая, что денормализация является широко цитируемым методом повышения производительности.