Хорошая или плохая идея для структуры CMS?

Question

Итак, я собирался сделать CMS и мне просто хотелось несколько вариантов.

Идея проста, но никто, кажется, не делает этого, поэтому с идеей должно быть что-то не так, верно?

По сути, у меня будет таблица с именем 'fields'. Эта таблица будет содержать отдельные поля данных. Тогда у меня будет вторая таблица с именем data_node, которая представляет собой группу полей для создания объекта данных.

Итак, data_node - это запись в блоге. Этот data_node будет иметь 4 поля. Название, содержание, создано, опубликовано.

В таблице полей будет 4 записи, в таблице data_node будет 1 запись

На уровне PHP у вас будут модули, которые будут обращаться к узлам данных.

Есть ли обратная сторона этого? Было бы много работы для одного стола, но для средних сайтов это не было бы проблемой, верно?

Answer 1

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

Как вы, очевидно, поняли, структуры EAV обеспечивают очень гибкое хранение однородных данных, поскольку вы абстрагируете все, что определяет то, что «есть», в другой слой данных. Плюсом является гибкость, но минусов много:

• Нельзя навязать ссылочную целостность (на физическом уровне невозможно определить, что конкретный тип объекта должен содержать значения для некоторых полей, включая отношения между объектами)
• Хранение неэффективно, так как вы должны рассчитывать на наименьший общий знаменатель. Другими словами, если вы храните содержимое сообщения в блоге, каждое сохраненное вами значение должно храниться в очень большом символьном поле. Не символьные данные (например, ваши даты или числа) должны быть преобразованы в и из строк при использовании их в приложении
• Объединения становятся утомительными, чтобы писать. Хотя это верно и для проектирования баз данных 6NF и не является непреодолимым препятствием, стоит отметить. Для любого поля, которое необходимо преобразовать в столбец в наборе результатов (другими словами, если вы хотите вернуть только одну строку для публикации, с полями, которые вы определили как столбцы, вместо того, чтобы возвращать несколько строк для сообщения с полями, которые вы определили как строки), требуется собственное объединение. Это (или не должно быть, в зависимости от вашей RDBMS ... если вы используете PHP, я предполагаю, что вы используете MySQL, и я не могу говорить о том, как он обрабатывает много соединений), не проблема для базы данных, но это затрудняет написание ваших запросов.

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

Answer 2

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

Минусы, из моего опыта:

• Вам придется забыть ссылочную целостность с обычными методами sql. Нет внешних ключей, нет «каскада на удаление» и т. Д.
• Вы будете много заниматься метапрограммированием. Это хороший вызов, но внезапно станет очень трудно исправлять ошибки, пока вы не привыкнете к нему.
• Не все поля имеют одинаковый тип данных. Либо в ваших полях таблицы потребуется больше столбцов, либо вам придется преобразовать все в VARCHAR и обратно.