Принцип построения моделей БД для PHP?
Здравствуйте, Владислав

У Вас в профиле ссылка на очень хорошую книжку Мартина Фаулера: martinfowler.com/books.html#eaa

Из неё про Active Record: martinfowler.com/eaaCatalog/activeRecord.html
Data Table Gateway: martinfowler.com/eaaCatalog/tableDataGateway.html
Data Mapper: martinfowler.com/eaaCatalog/dataMapper.html

Теперь немного рассуждений из личного опыта.

Привязка доменной модели к реляционной сложна исходя из следующих факторов:

* Гранулярность (доменная модель часто имеет большую детализацию)
* Наследование (нужно выразить в реляционной схеме данных)
* Идентичность (определяется равенством но коде и ID в БД)
* Ассоциации (один ко многим в коде выражается массивом, в схеме БД через внешние ключи)
* Навигация по данным (в коде — ссылки, в схеме БД joins)

В случае, если доменная модель сложна, и мы сталкиваемся со множеством перечисленных трудностей, то рекомендуется использовать Data Mapper. Это позволит доменным объектам не беспокоиться о существовании БД.

Если предметная область не слишком сложная, то может быть удобным добавить Persistence методы к классам доменной модели (Active Record). Это облегчит программистам процесс написания сервисного кода.

В случае, если доменная модель удобно ложится на реляционную схему, но мы всё равно хотим обособить SQL для соблюдения принципа персональной ответственности, то рекомендуется использовать Data Table Gateway

Это довольно общие слова. Если уточните вопрос, буду рад уточнить и ответ :)
Спасибо за ответ.
После знакомства и применения этих патернов, у меня возникла уйма вопросов, на которые я не могу найти ответ :)
Хотел бы узнать какие патерны используют в больший проектах и чем это оправдано?
В каких случаях лучше применить тот или иной паттерн?

После использования Data Mapper (Doctrine 2) я смог выделить такие
Плюсы:
 — Действительно удобное разделение логики работы с БД
 — Генерация SQL кода (CREATE TABLE)
Минусы:
 — Реализация сложных выборок
 — Оптимизация запросов
 — Выделение коллекций
 — Все нужно делать через entity manager
 — «Кушает» много памяти

AR плюсы:
 — Вынесение работы с БД на уровнень вверх
 — Простота использования
Минусы:
 — Неввозможное сокрытие данных
 — Сильно много ответвеснности на одном классе
 — Сложность наследования классов

Data Gateway (Zend_Table):
 — Вынесения логики для работы с таблицей в отдельный класс и на верх
 — Работа с коллекциями (Rowset)
 — Удобно разширять модели, и все действительно гибко
Минусы:
 — Нужно создавать много практически пустых классов
 — Сложность наследования

Действительно я все правильно понял?