Проектирование базы данных PHP/MySQL для различного / переменного содержимого - модульная система

Я пытаюсь создать (сейчас просто размышляя / планируя / рисуя отношения:]) небольшую модульную систему для создания базовых веб-сайтов (в основном, чтобы упростить общие задачи, которые мы, веб-дизайнеры, делаем регулярно).

Я немного застрял с дизайном базы данных / целой идеей хранения контента.

1. Что наиболее болезненно для большинства веб-сайтов (из моего опыта), так это страницы с квази одинаковым макетом / скелетом, с различной информацией - например, заголовком, изображением и набором информации - но с созданием специальных шаблонов / специальных модулей в cms случается, что стоит больше энергии, чем редактировать его как текст - однако здесь мы теряем некоторый операционный потенциал - мы не можем получить "только заголовки", потому что CMS/system воспринимает весь контент как одно текстовое поле

Итак, я хотел бы, чтобы эти две таблицы - одна для хранения информации о структуре контента (например, просто переменное количество фотографий <1;500):], заголовок, текст и фото (большие) и галерея) - КАК - и другая таблица со всем содержимым, модулями и частями "сборников" (мое рабочее название для различной структурированной информации) - ЧТО

table module_descriptors (HOW)  
id int  
structure - *???*  

table modules (WHAT)  
id int  
module_type - @link to module_descriptors id
content - *???*

2. Что мне нравится в этом - мне не нужно много таблиц - мне не нравятся базы данных с 6810 таблицами, по одной для каждого модуля, для его описания, для разного. отношение числа к тексту,... и я также не люблю таблицы с 60 столбцами, как content_us, content_it, category_id, parent_id,

Я думаю, что мог бы хранить описание структуры и сам контент (отмеченный как ????) Как XML или CSV, но, возможно, я пытаюсь заново изобрести колесо, и ответ на него скрыт в каком-то шаблоне проектирования, которого у меня нет ". т смотрел в.

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

РЕДАКТИРОВАТЬ: Мой вопрос также заключается в следующем: имеет ли этот подход смысл? Это для редактирования? Есть ли что-то лучше? Это морально? Разве котята не умирают, когда я это делаю? Не слишком ли это для сервера, если я хочу прочитать и сравнить 30 XML-файлов, извлеченных из БД (например, я хочу сравнить что-то)? Техническая часть - как это сделать - это только одна часть вопроса:)

Источник

1 ответ

Решение

Шаблон дизайна, на который вы намекаете, называется Serialized LOB. Вы можете хранить некоторые данные обычным способом (в виде столбцов) для атрибутов, которые одинаковы для каждой записи. Для атрибутов, которые являются переменными, отформатируйте их как XML или MarkDown или как хотите, и сохраните их в ТЕКСТЕ BLOB.

Конечно, вы теряете возможность использовать выражения SQL для запроса отдельных элементов в BLOB. Все, что вам нужно использовать при поиске или сортировке, должно быть в обычных столбцах.

Комментарий: если ваш текстовый BLOB-объект находится в формате XML, вы можете искать его с помощью функций XML, поддерживаемых MySQL 5.1 и более поздними версиями. Но индекс не может извлечь выгоду, поэтому он приведет к очень медленным поискам.

То же самое верно, если вы пытаетесь использовать LIKE или же RLIKE с подстановочными знаками. Без использования индекса поиск приведет к полному сканированию таблицы.

Вы также можете попытаться использовать индекс MySQL FULLTEXT, но это не очень хорошее решение для поиска данных XML, потому что он не сможет определить разницу между текстовым содержимым, именами тегов XML и атрибутами XML.

Так что просто используйте обычные столбцы для любых полей, которые вы хотите найти или отсортировать по. Вы будете счастливее таким образом.

Вопрос: Если ваши документы действительно требуют переменной структуры, у вас есть несколько вариантов. При правильном использовании SQL предполагает, что каждая строка имеет одинаковую структуру (то есть столбцы). Ваши альтернативы:

Некоторые люди используют антипаттерн Entity-Attribute-Value (EAV) для хранения переменных атрибутов, но, честно говоря, не идут туда. Для истории о том, как плохо это может пойти не так, прочитайте эту статью: Bad CaRMa.

Источник
Другие вопросы по тегам