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

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

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

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

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

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 Ответ

1 голос
/ 26 января 2010

Шаблон дизайна, на который вы намекаете, называется 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 .

...