Я нигде не приводил равнозначности нагрузки и количества записей в БД, прошу прощения, если неправильно формулировал.
Я ничего не имею против реализации AR в целом, я просто пытаюсь сказать, что ее использование уместно не всегда. Вы же меня как будто не слышите и тычите мне в лицо очевидными постулатами.
При чем тут СУБД, если мы говорим о конкретной реализации конкретного шаблона проектирования, а если точнее о ее минусах? И при чем тут мое место работы, оно как-то влияет на эту эти минусы? Я всего лишь говорю, что данная реализация не подходит для нагруженной работы с крупными данными, и у меня есть примеры, когда в продакшене от этого было реально больно. Вы утверждаете, что дело в архитектуре БД/Приложения, возможно, вы сможете привести контрпример?)
Вы хотите сказать, что есть возможность спроектировать реляционную БД с миллионными табличками так, что производительность сильно нагруженного приложения, построенного с применением YII AR будет сопоставима с производительностью того же приложения, использующего для доступа к данным «простые запросы»?
Ну, разница в производительности выполнения одного и того же запроса, построенного через тот же command и те же criteria легко может составлять до десятка раз.
Столкнулись на большом продукте с адовыми тормозами ActiveRecord и непрозрачностью DefaultScope'ов. Действительно, эти подходы годятся только для совсем маленьких сайтов.
Я ничего не имею против реализации AR в целом, я просто пытаюсь сказать, что ее использование уместно не всегда. Вы же меня как будто не слышите и тычите мне в лицо очевидными постулатами.