У меня есть основная база. К примеру назовём её "База Человек"..

В основную базу входят следующие данные
- ФИО
- Дата рождения
- Место рождения

Будем считать что это постоянные данные которые даны при рождении.

Теперь по мере роста сайта и расширения информационной составляющей мне необходимо расшить информацию о Человеке.

Вот тут мне и нужно организовать систему расширений (plugins). Допустим нужно ввести следующие характеристики:
- Место жительства
- Цвет волос

Каждая характеристика я так понимаю должна выполнять следующие функции:
- Вывод информации на сайте
- Изменение информации
- Поиск по этой информации (или по ключевым моментам). Например, Адрес содержит несколько характеристик, а Цвет волос, только одну..

Собственно вопрос. Как организовать работу с подключением (удалением) этих расширений? Буду рад любым жизненным опытом и даже материалами по этой теме (только на русском)..

Мне кажется, требования слишком мало описаны. Ладно характеристики 1 к 1. А список к человеку (список детей, например) нужен? Фактически, это сводится к вопросу, могут ли характеристики иметь комплексный тип?
Вообще, мне видится примерно такой способ: добавляется плагин (к примеру из админки), проверяется файл, в котором описаны все связи плагина с самой системой, зависимости от других плагинов, типы предоставляемых данных (они должны быть заранее описаны в спецификации), добавляемые таблицы. Эта вся муть после проверки удовлетворения зависимостей импортируется вовнутрь, как бы встраивается; создаются таблицы.
Например, в том же ZF (на сколько я помню) можно связывать модели друг с другом, указывая в самой модели список привязываемых. По тому же принципу можно это дело записывать в отдельный файл, из которого связи динамически вытаскивать при формировании запросов.
Я правильно понял существо вопроса?

наверное правильно, вот только я малость не понял суть ответа 

Чуть поясню как я это вижу...

Допустим плагин ColorHair (цвет волос).. В плагин допустим входят следующие файлы:
plugins
---colorhair
------colorhair.css (собственные стили)
------colorhair.js (если вдруг понадобятся дополнительные скрипты)
------colorhair.php (сам класс)

в базе существует таблица плагинов
- идентификатор плагина
- название (colorhair)
- описание (цвет волос)
- статус публикации

потом согласующая таблица
- идентификатор
- идентификатор плагина
- идентификатор объекта
- значения (обычное текстовое поле с параметрами) Например
   color=чёрный
   natural=крашеный

colorhair.php



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

Это сообщение отредактировал(а) Gold Dragon - 22.4.2011, 08:18

Можно идти к архитектуре от потребностей приложения ;)
К примеру, основной вывод информации идет у нас в следующих видах
сайт:
-- табличный вид всех человеков, верстается таблицами.
-- структурный вид одного человека, сверху-вниз, каждая категория с картинками
админка:
-- вид админки с возможностью редактирования одного человека, сверху-вниз, каждая категория с полем ввода
-- админка с настройкой плагина

результатом подключения плагина должно стать 
-- 1.  добавить пару ячеек в таблицу
--  2.3. добавить несколько новых полей в простыню. И не в порядке перечисления плагинов приложения, а в порядке определенном заказчиком/дизайнером 
-- 4   дополнительная форма 

на этом этапе нужно ответить себе - как плагин будет поддерживать разные способы вставки информации в исходящий вывод приложения?
Ответы:
-- приложение должно содержать в себе "умный" шаблонизатор, который по предъявленным данным сам строит то, что ему надо. В этом случае, при добавлении нового плагина с большой вероятностью придется дополнять основной шаблон приложения.
-- приложение содержит в себе набор шаблончиков для каждой новой возможности вывода информации. Тогда при вставки плагина в новое приложение с большой вероятностью придется допиливать шаблончики под новые потребности приложения.