Совсем недавно я написал о задании для программиста, которое мне прислали, где нужно было найти натуральные числа на Transact-SQL (читаем заметку здесь). Там было ещё два задания, которые я точно не помню, но смысл в том, что они легко решаемы, но нужно писать процедуру или какой-то другой код на стороне Transact-SQL.
В той заметке я так же спросил, что говорит такое задание. Для меня это говорит то, что компания очень много использует хранимых на сервере базы данных процедур и/или функций, а я такое не люблю, поэтому в такой компании не очень горю желанием работать. И объясню почему.
Если переносить логику на базу данных, то на неё увеличивается нагрузка. Хранимые процедуры с курсорами, циклами и так далее обходятся серверу не дёшево, да и в любом случае, даже дешёвые операции лучше лишний раз не кидать на сервер. Базу данных очень тяжело масштабировать горизонтально. Можно наращивать мощность процессора, увеличивать размер оперативной памяти, но ставить два сервера одновременно не так уж и легко.
Самый простой метод горизонтального масштабирования MS SQL Server - сделать один сервер основным и добавить ещё сколько угодно серверов только для чтения и настроить репликацию. На моей практике репликация уже давала сбои и не раз, поэтому этот метод нельзя назвать 100% надежным и если этот процесс нарушается в работе, то возникают серьёзные проблемы.
Сервера приложений масштабировать очень просто, ставим балансировщик нагрузки, который швыряет запросы к разным серверам приложений, а все сервера приложений работают независимо, но соединяются к одной и той же базе данных. Уже этого достаточно для меня, чтобы не перегружать SQL Server лишними расчётами.
Вторая причина - переносимость. Если писать запросы только на чистом SQL, то переход на другую базу можно совершить на много проще, чем если писать все в виде хранимых процедур. Если вся логика реализована на базе данных, то её полностью придётся переписывать.
Отлаживать код на сервере сложнее, возможности Transact-SQL на много слабее, чем любой нормальный язык и тут даже нечего сравнивать с C#. Зачем извращаться писать код на Transact-SQL, когда можно использовать все прелести .NET?
Я использую хранимые процедуры и функции только при создании отчетности. Вот тут я люблю, чтобы все выполнялось на сервере - просто запускаешь SQL запрос и в результате получаешь готовый отчёт, который не должен дополнительно обрабатываться на сервере приложений.
Для меня задание этой компании указало на то, что там явно слишком сильно используется Transact-SQL. Я не говорю, что это не правильно, я просто не люблю такое и привел свои доводы в этой заметке. Поэтому я не стал выполнять задание. Возможно я не прав, и там SQL используется не так уж и сильно, как я подумал.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
В целом ты прав - db engine слишком сложно масштабируемый, и поэтому дорогой ресурс, чтобы его загружать бизнес логикой. Добавим к этому очень ограниченные и весьма костыльные возможности CI, чтобы окончательно отбить у себя желание писать когда-либо писать "create procedure".
Ну и репортинг силами сиквела это по сути рудиментарный пережиток прошлых лет.
Слишком много "если" для однозначного ответа на вопрос, стоит ли писать логику на стороне DB. Иногда стоит, иногда нет, иногда стоит часть делать на стороне базы и часть на стороне приложения. Но очень часто встречаются крайности - только Transact-SQL или только C# (хотя их даже сравнивать не совсем корректно).
У меня были случаи, когда вопрос масштабируемости SQL server решался пересмотром data flow процесса.
"Если писать запросы только на чистом SQL, то переход на другую базу можно совершить на много проще, чем если писать все в виде хранимых процедур" - возможно мне не везло, но я такого не видел такого перехода ни разу, но требовение "pure SQL etc." не давало использовать фич конкретной СУБД (собственно как раз то, из-за чего тот же SQL Server / Oracle etc. стоит дорого)
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
