База данных в базе данных (а-ля CCK без Drupal)

Question

Я надеюсь создать библиотеку Codeigniter, похожую на CCK Drupal, хотя и в чрезвычайно упрощенной версии. Мне интересно, какая структура базы данных будет работать лучше всего для достижения моей конечной цели, которую лучше всего описать в следующем сценарии использования:

Интерфейс:

Существующие типы контента:

• Страница [тип редактирования] [список всех] [добавить новую страницу]
• Рейтинг [тип редактирования] [список всех] [добавить новый рейтинг]
• DVD-фильм [тип редактирования] [список всех] [добавить новый DVD-фильм]

[создать новый тип контента]

Веб-разработчик нажимает [создать новый тип контента]:

Форма: новый тип контента

Введите название: [ _ Комментарий посетителя __ _ __ _ __ _ ___ ]

Добавить поле:

• Имя поля: [ _ Имя __ _ __ _ __ _ _ ]
• Тип поля: [ Текст (<128 символов) </strong>] (раскрывающийся список с основными параметрами)
• Обязательное значение: [ x ]
• [Добавить поле]

[Сохранить тип содержимого]

Веб-разработчик добавляет пару полей:

Форма: новый тип контента

Введите название: [ _ Комментарий посетителя __ _ __ _ __ _ ___ ]

Текущие поля:

1. Имя | Текст (<128 символов) | требуется </li>
2. Email | Текст (<128 символов) | по желанию </li>
3. Содержание | Текст (<1024 символа) | требуется </li>
4. ForPage | Страница | требуется

Добавить поле:

• Имя поля: [ _ __ _ __ _ __ _ __ _ ]
• Тип поля: [-выберите ниже-]
• Обязательное значение: []
• [Добавить поле]

[Сохранить тип содержимого]

Веб-разработчик сохраняет тип контента, а система создает ...... ну, что именно?

Идея 1: Я мог бы легко позволить ему создать новую таблицу БД с соответствующими полями (которая по существу сформировала бы очень элементарную систему phpmyadmin) - но разумно ли это? Разве это не засоряет базу данных множеством таблиц для этого и того?

Идея 2: Или я мог бы создать «базу данных в базе данных», что-то вроде:

table ContentType (e.g. "Book")
-- id
-- title

table CustomField (e.g. "Author Name")
-- id
-- ContentTypeID (linking the "Author Name" field to the "Book" type)
-- valueType (linking the field to the correct db table of values)

table DBRecord (e.g. "Lord Of The Rings vol.1")
-- id
-- ContentTypeID (linking the LotR record to the "Book" type)

table ValueText128 (e.g. "J.R.R. Tolkien")
-- id
-- DBRecordID (linking the value to the LotR record)
-- CustomFieldID (linking the Tolkien value to the "Author Name" field)
-- value : char(128)

table ValueSmallInt (e.g. "1954")
-- id
-- DBRecordID (linking the value to the LotR record)
-- CustomFieldID (linking the "1954" value to the "Published Year" field)
-- value : smallInt

...and so on, with a table for each of the datatypes

Возможно, это может сработать, но я подозреваю, что на практике это может быть ужасно неэффективно, учитывая, что каждое целочисленное значение из каждого элемента каждого типа во всей системе окажется в одной и той же массивной таблице - и то же самое для каждого символа ( 128) значение и т. Д.

Итак - что ты думаешь? Как CCK это делает? Что будет работать лучше?

Answer 1

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

Попробуйте увидетьесли вы можете определить набор различных архетипов в домене, для которого вы собираетесь использовать эту систему.Например: «Страница», «Рейтинг», «Мультимедиа», «Комментарий», «Пользователь» и т. Д. Установите фиксированные схемы и реализации для этих случаев, но разрешите конкретным экземплярам настраивать метки полей, а такжеполя для показа.Для еще большей гибкости вы можете предложить (ограниченные) способы настройки правил проверки полей.

Вы можете дополнить архетипы настраиваемыми общими полями, как вы описали в идее 2, при условии, что основной контентпокрыта фиксированной схемой.

Я думаю, что динамическое создание специальных таблиц быстро создало бы беспорядок, и его было бы сложнее отлаживать и поддерживать.Если вы упрощаете динамическое создание таблиц, как насчет изменений в дальнейшем?Вы можете изменить существующие таблицы, но перенос старых данных может быть очень трудным, если не невозможным, в зависимости от типа изменений.

Answer 2

Я нашел статью Роберта Дугласа, которая в значительной степени отвечает на мой вопрос:

Что такое комплект конструирования контента? Вид из базы данных