#mysql #database #database-design
#mysql #База данных #проектирование базы данных
Вопрос:
Допустим, у меня есть объект, который будет иметь много атрибутов, некоторые из которых я знаю сейчас, а другие будут определены пользователем. Каков наилучший способ смоделировать это?
1) Есть ли у меня основная таблица и связываю ли я ее со вторичной таблицей пары имя-значение? Все атрибуты передаются во вторичную таблицу EAV.
- или —
2) Помещать ли мне наиболее распространенные атрибуты (они понадобятся не всем пользователям, поэтому я ожидаю много нулевых записей) в основную таблицу и иметь вторичную таблицу EAV для пользовательских атрибутов?
- или —
3) Какой-то другой подход, о котором я не подумал?
Ответ №1:
Вы можете использовать второе решение по соображениям эффективности, в частности, если вам нужно часто выбирать эти величины. Эти значения могут быть «кешем» таблицы EAV, если хотите. Вы вводите дублирование, но ускоряете поиск.
EAV — хорошее решение для этой проблемы, если только вам не нужно выполнять объединения на уровне базы данных. Альтернативой является отказ от реляционной модели и переход к модели, основанной на RDF.
Ответ №2:
Как правило, большое количество пустых ячеек обходится дешево и не стоит их нормализации. Единственный недостаток, возвращающийся к пункту 2, заключается в том, что у вас очень большое количество строк (миллионы — где могут возникнуть проблемы с производительностью), очень большое количество столбцов (более 20 — где просто неприятно смотреть на данные) или существует ряд уникальных ограничений на таблицу EAV.
С учетом сказанного, сейчас 2011 год, и в наши дни имеет смысл использовать фреймворк программирования со уровнем абстракции базы данных, чтобы вы не проектировали отношения с базой данных напрямую. Что-то вроде объектно-реляционного Mapper от Django позволяет вам сосредоточиться на самих моделях и позволить лучшим практикам позаботиться о себе (95% времени). Этот учебник поможет вам начать. Django применяется только к моделированию базы данных веб-разработки. Для не веб-сред другие фреймворки будут лучше.
Комментарии:
1. Я рассматриваю возможность использования Doctrine, хотя признаю, что все еще не совсем понимаю концепцию ORM. Я не понимаю, как ORM делает так, что я «не проектирую отношения с базой данных напрямую». В настоящее время я работаю над этой моделью в MySQL Workbench и прохожу большой анализ данных, просто чтобы понять взаимосвязи моих данных. Как ORM освобождает меня от этого?
Ответ №3:
Я проделал большую работу с шаблоном EAV, и он достаточно хорошо послужил своей цели. Я нахожу, что с пустыми столбцами или динамическими столбцами (такими как col1, col2 и т.д.) Гораздо сложнее иметь дело с управлением постфактум, но может быть проще запросить их, поскольку вам не нужно столько соединений.
Одна вещь, которую я бы очень настоятельно рекомендовал, — это взглянуть на такие опции, как Mongo DB. Он автоматически обрабатывает сложные динамические структуры данных.