Intellect Board — cистема управления сайтом

Сейчас наиболее сложной проблемой с точки зрения реализации IntB является реализация задаваемых полей.
На данный момент рассматриваются следующие варианты:
1. Каждому типу страниц сопоставляется одна таблица с задаваемыми полями + имеется одна таблица с метаданными (т.е. описанием того, что в этих таблицах хранится и как это отображать в пользовательской форме). Имя таблицы с задаваемыми полями хранится в таблице prefix_types. (Нечто аналогичное применяется в IntB 2.x, только там нет таблицы с метаданными.)
Достоинства подхода: а) простая реализация выборки/изменения, а также сортировки или выборки по сложному условию, б) количество SQL-запросов для получения данных остается неизменным по сравнению с исходным вариантом.
Недостатки: а) отсутствие возможности наследования или наличия одинаковых полей у разных типов, б) невозможность создавать задаваемые поля для отдельно взятых разделов, в) невозможность универсальной конвертации из типа в тип.

2. Вводится понятие "набор полей", и вместо одной таблицы метаданных, которая была в первом варианте, добавляются 3: список всех существующих наборов полей (fieldset), список наборов полей, принадлежащих конкретному типу или странице, и список самих полей, принадлежащих конкретному набору.
Достоинства подхода: а) возможность задавать поля не только типам, но и отдельным страницам/контент-системам, б) по-прежнему достаточно простой остается сортировка/выборка по сложному условию, в) становится в принципе возможной конвертация из одного типа страницы в другой.
Недостатки: а) добавляется 1 или 2 лишних запроса к БД на получение списка контент-полей по типу, б) существенно усложняется основной запрос получения данных — к нему присоединяются через LEFT JOIN все таблицы, которые участвуют в запросе, в) необходимо описывать и редактировать эти наборы полей.

3. То же самое, что и 2, но отсутствует понятие "набор полей". Таким образом, мета-таблиц становится две: одна содержит список существующих полей, другая — список принадлежности их определенным типам или страницам. При этом сами задаваемые данные хранятся всего в одной таблице, имеющий три столбца — id поля, id страницы, значение задаваемого поля.
Достоинства: а) полная свобода сопоставления полей любому типу или странице, б) предельно простая конвертация типов страниц.
Недостатки: а) очень сложные SQL-запросы для извлечения полей (т.к. делается многократный JOIN этой таблицы, плюс программно необходимо принимать меры для избегания дублирования имен полей), б) сложная операция редактирования полей, в) сложности с сортировкой из-за того, что все поля принудительно приводятся к текстовому виду
Достоинства: а) существует единый индекс для всех полей (в вариантах 1-2, скорее всего, пришлось бы предусматривать выбор, делать поле индексируемым или нет), б) отсутствие необходимости создавать множество таблиц.

4. То же самое, что и вариант 3, но выборка не одним запросом с огромным количеством LEFT JOIN, а множеством простых запросов в цикле.
Достоинства: а) те же, что и у варианта 3, б) более простые запросы
Недостатки: а) существенно усложняется выборка по сложному критерию и/или сортировка.

На данный момент я больше всего склоняюсь к варианту 2.

Yuras, я думаю мысль была посоветоваться и обсудить что лучше. Или чтобы другие разработчики предложили другие мысли.