@phpcoder81

Как совместить реляционную модель бд с ООП?

Есть два класса: Товары и Бренды. Оба по идее должны быть независимы, если бы не тот факт, что у Товара есть поле brand_id.
На ум пришло соединять их в промежуточном классе Коллекций. Перебором объектов.
Неужели сама идея реляционных бд с ООП несовместима?
Или все же модифицируются в дальнейшем классы, переписыванием кода?
Ps. Надеюсь вы поняли мой вопрос)
  • Вопрос задан
  • 289 просмотров
Решения вопроса 1
FanatPHP
@FanatPHP
Чебуратор тега РНР
Неужели сама идея реляционных бд с ООП несовместима?


Ты весьма недалёк от истины.
Некоторые сравнивают эту проблему с проигранной США войной во вьетнаме.

Решение от Victhor подходит для единичных выборок, но как быть с коллекциями? Люди начинают изобретать разные стратегии подгрузки - lazy loading, eager loading. Вот Елоквент, например, собирает в кубышку все айди загруженных товаров и потом пуляет 1 запрос с IN (...) чтобы получить для них бренды, которые потом в цикле пришпандоривает к товарам.

Но все это очень быстро начинает сказываться на производительности. И всё дальше затягивает нас в пучину Вьетнамской войны, или другими словами в кроличью нору Object-relational impedance mismatch - как по-научному называется озвученная тобой проблема. Дальше начинается совсем уж треш и угар, типа дико тормозащих коллекций в Доктрине или таких извращений, которыми занимался один мой знакомый - он плодил вьюхи в БД, поскольку его ОРМ умел работать только с одной таблицей.

Или все же модифицируются в дальнейшем классы, переписыванием кода?


В одном ты можешь быть уверен: такое легкое отображение, которое рисует тебе воображение при первом знакомстве с ORM - чтобы так хоба-хоба, и у нас записи из БД отобразились в объекты - увы, не существует. Да, приется переписывать, и много. И чем сложнее взаимосвязи, тем хуже будет работать автоматизация.

И тут на первый план выходит организация ORM и становится очевидной превосходство стратегии Data Mapper, когда слой работы с БД полностью отвязывается от объекта бизнес-логики.

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

Некоторые идут ещё дальше, и не пишут методов, которые возвращают универсальную коллекию, а пишут отдельный метод для каждого случая, когда требуются данные товара - для каталога один, для корзины - второй и т д.

И это мы сейчас говорим о read-моделях, и даже не трогали тему write models - то есть сохранения измененного объекта - со всеми гроздьями смежных объектов(!) - в БД!
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы