Comments 8
Вообще, двусторонние связи не очень хорошо, особенно связи ManyToMany. Помнится, об этом говорил Marco Pivetta в своих докладах.
Самая простая проблема с которой мы можем столкнуться, это синхронизация связей объектов. Хотя может её пофиксил. Я с ней сталкивался около 4 лет назад.
Рекомендую всем к прочтению статью Marco Pivetta о гидрации данных:
https://ocramius.github.io/blog/doctrine-orm-optimization-hydration/
Additionally, reduce the amount of bi-directional associations to the strict necessary.
After all, code that is not required should not be written in first place.
Спасибо за статью, данная цитата заставляет задуматься. Я вернулся к работе над PHP проектами около года назад и с тех пор пользовал Доктрину и в хвост и в гриву даже с большими базами данных. Нареканий даже в плане быстродействия не заметил — все в рамках приемлемого.
С другой стороны помню печальный опыт семилетней давности. Я очень часто натыкался на превышения допустимых объемов используемой памяти при работе с таблицами от 10к записей. Местами даже самим приходилось допиливать. Ограничивали буквально все. В одной критической сущности вообще от связей отказались, так как она была завязана на скрипт-краулер (он работал не менее минуты) и, как ни удаляй уже не нужные объекты из памяти, где-то внутри все равно происходило паразитное накопление приводящее к фатальным ошибкам.
С тех пор я вижу три фактора, которые на мой взгляд могли исключить эту проблему:
- существенная эволюция PHP, а именно появление Слабых ссылок
- сильно не вникал, но раз уж существует ReactPhp, то и со сборщиком мусора не хило поработали в новых версиях
- семилетний этап развития самой библиотеки Doctrine
Вообще поднятая вами тема заинтриговала. С пол пинка я не нашел достаточно информации. Если кто-то найдет пруфы к текущему состоянию дел на этот счет или сможет воспроизвести проблему — будет круто, поразбираем.
php bin/console doctrine:generate:entity --entity=AppBundle:User --fields=«username:string(127) password:string(127)» -q
Это ад.
Вы сущность на 2-3 десятка полей так же задаёте?
Вы сущность на 2-3 десятка полей так же задаёте?
Разумеется нет! Но чаще большие сущности не появляются сразу с огромным количеством полей. Они такими становятся в процессе разработки. Так что создать через консоль сущностью с 3-мя полями на этапе прототипизирования проще чем вручную — сами создаются файл сущности и файл репозитория сущности + папка для репозиториев сущностей, если не создана до того. А потом уже эта заготовка подходит для заполнения произвольным набором полей.
Моя практика показывает, что при наличии хорошей экспертизы в предметной области ваши сущности сразу будут большими. Но только те, кто действительно это требует.
Чаще сущность появляется сразу маленькой у человека уже с опытом в разработке, но без опыта в предметной области.
Но в любом случае проектировать БД посредством ERM диаграмм проще чем писать в консоли что-то невнятное.
А уж потом по готовой схеме генерировать классы Entity.
Консольная команда для этого имеется
Добавлю свои 5 копеек.
Этот подход называется Data-Driven Design.
С недавних пор, я предпочитаю использовать Domain-Driven Design методологию.
Не буду утверждать, что она лучше. Пусть каждый решает сам как и где ее применять.
Скажу лишь, что я в процессе разработки описываю доменные сущности и бизнес транзакции и лишь потом описываю маппинг на БД и генерю миграцию.
Чтоб не повторяться, вот хорошая статья по сравнению этих методологий.
А уж потом по готовой схеме генерировать классы Entity.
Консольная команда для этого имеется
How to Generate Entities from an Existing Database
Называется это Reverse Engineering — так же называется и аналогичная функция в MySQLWorkbench. MySQLWorkbench переводится как «MySQL скамейка» (Шутка. Называю ее так за исключительную глючность в Линукс среде)
Спасибо Fortop за дополнительную инфу для читателей. Хоть я и не разделяю таких подходов — они могут быть полезны для многих в определенных ситуациях.
Джентльменский набор Doctrine 2 для Symfony 3.3.6: Создание сущности, ассоциации и рекурсивные связи