Злоупотребление SQL-запросами

в 9:26, , рубрики: sql, Программирование, разработка, метки: ,

Возможно это стресс от моего текущего проекта, и то, что я здесь написал всего лишь крик моей души. Но, увы наболело.
Просто я заметил что некоторые разработчики (на мой взгляд, их очень большое количество) любят злоупотреблять SQL-сервером.
Возможно это из-за того что написать сложный sql-запрос все-таки проще чем грамотно спроектировать систему, которая будет организовывать гармоничное взаимодействие между объектами, и будет это делать быстро.

В чем собственно проблема.
Есть N-количество объектов, которые между собой связанны каким-то образом.
Каждый из объектов имеет свое место редактирования на пользовательской стороне.
И при этом пользователи хотят видеть в некотором объекте некоторую информации о его связях с другими объектами. Здесь на сцену и выходит всё могущество sql-запросов.
Для ускорения вывода информации об объекте (с учетом его связей с другими объектами) и происходит написание зловещего sql-запроса, который достает всю необходимую информацию по объекту и всю необходимую информацию по связям с другими объектами (при этом происходит получение непосредственно значений полей из связанных объектов). Данный запрос максимально оптимизируется и вроде как на клиенте получение информации происходит моментально.
Но с временем, требования к выводимы данным меняются и дополняются, а вместе с ними и меняется и незаметно усложняется сам запрос. Но даже и это не проблема, пока все идет хорошо (ведь мы умеем оптимизировать запросы).

Вот-вот прорвет
Самое интересное происходит, когда вроде как все довольны выводимыми данными. Происходит активная работа с каждым из объектов, и как обнаруживается, что информация динамически не меняется в ранее полученном объекте и его связях с остальными объектами.
Хорошо, если связь между объектами прозрачная и не проходит через несколько промежуточных объектов (что бывает гораздо чаще). И тогда начинается подстановка костылей в самые разнообразные места, и добавление динамического обновления для новых объектов или связей становиться все сложнее и менее прозрачным. И к тому же мы упираемся в ту самую проблему, от которой хотели убежать, применяя sql-запрос, все становиться гораздо медленнее (из-за необходимости обновлений объектов).

Резюме
Очевидно, что оставлять все так нельзя (особенно если проекту предстоит развиваться). Но как же тяжело кого-то убедить набраться смелости и произвести переосмысление проблемы и постараться спроектировать более корректное решение (и от этого становится тоскливо).
На мой взгляд, необходимо стремиться, что бы данные по одному объекту получались из одного места, что бы не было дублирования источника данных. А использования выше описанных sql-запросов, при работе с динамическими данными, и нарушает данную концепцию.

П.С.
Мое личное мнение, что использование таких сложных sql-запросов, которое вытаскивают сложные связи, эффективно для построения отчетов по системе или для результатов поиска. Т.е. для статических результатов, от которых мы не ожидаем динамического обновления.

П.П.С.
Поскольку данное мнение лично мое, и возможно оно ошибочно, хотелось бы услышать мнение других (и если можно с аргументами, что бы можно было осмысливать).

Автор: Amid_Kiy

* - обязательные к заполнению поля