Решение уже принято. Пока мы решаем организационные вопросы и прочую дребедень можно уже потихонечку готовиться к работе.

Предпосылки...
Чего у нас нет. Мы не индусы, поэтому у нас нет армии способной решать проблемы числом. К тому же как показала практика создание проекта, в лоб помноженное на эволюционное развитие приводит к большим сложностям в плане поддержки и развития проекта.

Посему мы должны взять умом. А это значит, что наши решения должны быть максимально декларативными или иным словами быть максимально близки к спецификации системы.

Как следствие мы дложны во всю задействовать такие мощные средства как DSL-и, генерация кода и компонентный подход.

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

Это описание видится мне как некий DSL учитывающий как аспекты связанные с БД, так и аспекты связанные с бизнес-логикой и т.п.

Одной из сложных и важных задач при этом является генерация структуры БД и ее автоматическая реструктуризация на основе модели.

Примечание
В качестве СУБД у нас будет использоваться MS SQL Server, но разработка будет вестись так, чтобы можно было в последствии сделать решение и на базе других СУБД.

По сему нам нужно написать библиотеку которая будет считывать метаописание (модель), сравнивать его с БД и генерировать SQL (T-SQL в случае MS SQL) приводящий структуру БД в соответствие с моделью.

Более подробно этот процесс можно расписать так:
1. Этот код считывает описание модели из DSL.
2. Преобразует модель в некий объектный вид (набор ООП-объектов или варианты, сейчас не важно).
3. Считывает описание структуры БД.
4. Преобразует описание структуры БД в объектный вид аналогичный п. 2.
5. Сравнивает два описания (полученные на шагах 2 и 4).
Для всех несоответствий вызывает методы генерации структуры БД.
6. Методы генерации генерируют SQL-DDL-скрипт модифицирующий структуру БД. Для того чтобы генерация DDL-скриптов не стала сущим адом. Скрипт для каждой части стркутры БД описывается в виде текстового шаблона (отдаленно напоминающего $-строку Nemerle).
7. Вызываются макры генерации Nemerle-кода необходимого для поддержки сущностей описанных в модели.

В результате мы имеем сборку с кодом поддержки конкретной структуры БД и программу, при запуске которой будет производиться реструктуризация БД.

Это позволит нам хранить в репозитории SVN только описание модели (в текстовом), и синхронизировать структуру БД при запуске приложения на исполнение.

Это потребуется нам чтобы вести параллельную разработку включающую изменение структуры БД и избавит от проблем ручной синхронизации структуры БД и т.п.

Доступ к данным мы предполагаем вести с помощь Linq2SQL (бывших DLinq) или механизма его заменяющего.

Такой подход позволит решить следующие проблемы:
1. Избавиться от лишнего (оберточного) кода (функций, вся суть которых заключается в абстрагировании прикладного кода от работы с API БД).
2. Сделать работу с СУБД статически типизированной.
3. Прозрачно реализовать ряд важных сервисных функций типа — защиты, постраничной прокрутки (пэйджинга), кэширования данных и т.п.

За счет наличия модели возможно удастся избавиться от возни с джоинами и т.п., а так же статически (во время компиляции и в IDE) проверять соответствие запросов модели.

ЗЫ

Более подробно о движке таксовых шаблонов и поддержке Linq2SQL будет сказано в сообщениях ниже.