Тему создавал на RSDN, но там пока ничего не ответили.

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

1. Как реализовать загрузку и выгрузку модулей? Как хранить метаданные? Что разрешить менять модулям?
Пример: разрешить модулям добавлять новые таблицы, триггеры, ХП, столбцы к существующим таблицам, внешние ключи для связи с существующими таблицами... Для загрузки определяются специальные процедуры, принимающие метаданные модуля.
Более простой вариант — хранить данные всех модулей в отдельных БД. Но это будет неудобно с точки зрения производительности, так как часто в одном запросе потребуется использовать данные нескольких модулей. Также потребуется обеспечить целостность данных в целом, а не только для отдельных модулей.

2. Как разрешать конфликты имён? Как реализовать что-то типа пространств имён?
Пример: для каждого модуля при загрузке определяется UUID, использующийся в качестве префикса. При загрузке метаданных и при выполнении запросов, производится трансформация запросов с подстановкой префиксов. При выполнении запросов, присутствует возможность задавать alias-ы для пространств имён.
Вариант хранения данных модулей в разных БД здесь тоже был бы удобен, но не подходит по перечисленным выше причинам.

3. Как управлять зависимостями между модулями, а также правами доступа к данным других модулей; настройками безопасности?
Пример: Может быть, выявлять зависимости между объектами БД умеет СУБД? Иначе всё сложно.
Более простой вариант: вынести всё взаимодействие между модулями из БД, реализовать всё средствами ООП. Это не подходит, так как уменьшит производительность: часто требуется использовать данные разных модулей в одном запросе.

4. Как управлять версиями модулей?

5. Как реализовать что-то вроде типизации модулей — для наследования, полиморфизма (то есть, для указания, что один модуль может решать задачи другого)?
Пример: сверить сигнатуры хранимых процедур, и, возможно, явно задавать это в атрибутах модуля.
Также, было бы проще реализовать всё средствами ООП.

6. Допустим, в системе надо хранить данные нескольких модулей одного типа. Одновременно может работать только один из них. Нужно реализовать возможность "на лету" переключать один модуль на другой.
Пример: выполняется "блокировка модуля", запускается процедура конвертации данных (которая, в большинстве случаев, может отсутствовать), запросы транслируются на другой модуль.

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

Непонятно, что такое "загрузку и выгрузку модулей"
Модуль БД разрабатывается как проект типа Database Project в MS Visual Studio
Изменения схемы данных делается скриптами.
Системные данные добавляются скриптами.
То есть, при необходимости установить модуль, администратору прийдётся выполнить скрипт. Хотелось бы допускать, что администратор не обязан знать SQL и БД. Тогда он не обязан читать скрипт. Но скрипт может случайно удалить данные или нарушить целостность БД. Хотелось бы этого избежать. Например, чтобы администратор, при установке модуля, получил сообщение типа "Устанавливаемый модуль может изменять данные модуля users, продолжить (будет выполнена резервная копия данных модуля users)?".
Для примера, в обычном ПО, сейчас вряд ли кто-нибудь станет предлагать модульную архитектуру, в которой для установки модуля надо применить патч к исходникам и перекомпилировать их.

Пространство имён - префикс объектов модуля.
Например, объекты модуля "User" называются UserGroup, User_Read, User_Add
А если два модуля User, например, один - для авторов книг, а другой - для покупателей книг? - они могут быть совершенно разными, но при этом случайно иметь одинаковый префикс. Тогда скрипт не отработает или даже испортит данные.

1) Зависимости сущенствуют только "сверху вниз". Модули внизу (User) не зависят от модулей вверху (Order)
2) Модули вверху используют специально для этого предназначенные объекты из модулей внизу. И никакие другие.
Реализация нижних модулей может при этом меняться.

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

guest_a4. Как управлять версиями модулей?В VSS-е, как-же ещё? :-)
Я имею ввиду такие вещи, как конвертация данных при апгрейде (например, специальной процедурой), проверка совместимости.

guest_a5. Как реализовать что-то вроде типизации модулей — для наследования, полиморфизма (то есть, для указания, что один модуль может решать задачи другого)?
Пример: сверить сигнатуры хранимых процедур, и, возможно, явно задавать это в атрибутах модуля.
Также, было бы проще реализовать всё средствами ООП.В реляционных БД наследование и полиморфизм не поддерживаются :-(
Поддержка нужна, во первых, в менеджере модулей, во вторых, в запросах. Идея состоит в том, чтобы в запросах указывать вместо конкретных таблиц лишь тип модуля и имена в "интерфейсе", а при передаче на сервер БД, запросы будут транслироваться в запросы с настоящими именами таблиц конкретного модуля.

guest_a6. Допустим, в системе надо хранить данные нескольких модулей одного типа. Одновременно может работать только один из них. Нужно реализовать возможность "на лету" переключать один модуль на другой.
Пример: выполняется "блокировка модуля", запускается процедура конвертации данных (которая, в большинстве случаев, может отсутствовать), запросы транслируются на другой модуль.Не понял.

Приведите пример "нескольких модулей одного типа"???
Допустим, есть форум sql.ru и тип модуля "рейтинги сообщений". Одна из реализаций позволяет пользователям ставить друг другу рейтинги. Другая не позволяет этого делать, а вычисляет их сама на основе какого-нибудь интеллектуального алгоритма (анализируя дерево постов форума). Но данные о рейтингах имеют одну структуру. Было бы удобно у других модулей в списках зависимости указать не конкретный модуль, а его тип (интерфейс).

guest_a7. Как допустить, что некоторая конфигурация модулей влияет на работу всех пользователей, а некоторые модули могут свободно загружаться, выгружаться, отключаться отдельными пользователями, независимо друг от друга?По-моему, это черезмерное требование для СУБД как таковой.

Тем более - отдельные модули для пользователя. Это просто индивидуальные субд для пользователей.[/quot]
Да, здесь я уже загнул... Пока я ещё не понял, что из этих двух вариантов я имею ввиду:
- индивидуальные БД для пользователей, но использующиеся совместно с основной БД системы. Здесь подошли бы БД на клиенте - так проще и безопаснее. Но проблема в том, что в некоторых случаях разместить на клиенте БД нельзя. В web-е проблема решается с помощью сайтов mash-up-ов (пример: добавление wiki к google maps), в desktop-е, наверное, с помощью custom-клиентов. Недостатки таких способов в том, что данные прийдётся гонять между серверами вместо того, чтобы решить всё одним запросом. Хотя, раз уж БД пользовательские, то запросы не должны быть сложными.
- модули, устанавливающиеся по инициативе пользователя. Пользователь, установивший модуль, может пользоваться им сразу. Остальные пользователи могут также включить этот модуль. Пример: модуль "друзья". Пользователь устанавливает модуль и может сразу создавать свой список друзей, смотреть френд-ленту. Другие пользователи ничего не заметят, лишь увидят возможность "включить установленный модуль".