Почему я не пишу логику на Transact-SQL

18 Августа 2016 Программирование
2 0

Совсем недавно я написал о задании для программиста, которое мне прислали, где нужно было найти натуральные числа на Transact-SQL (читаем заметку здесь). Там было ещё два задания, которые я точно не помню, но смысл в том, что они легко решаемы, но нужно писать процедуру или какой-то другой код на стороне Transact-SQL. 

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

Если переносить логику на базу данных, то на неё увеличивается нагрузка. Хранимые процедуры с курсорами, циклами и так далее обходятся серверу не дёшево, да и в любом случае, даже дешёвые операции лучше лишний раз не кидать на сервер. Базу данных очень тяжело масштабировать горизонтально. Можно наращивать мощность процессора, увеличивать размер оперативной памяти, но ставить два сервера одновременно не так уж и легко. 

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

Сервера приложений масштабировать очень просто, ставим балансировщик нагрузки, который швыряет запросы к разным серверам приложений, а все сервера приложений работают независимо, но соединяются к одной и той же базе данных. Уже этого достаточно для меня, чтобы не перегружать SQL Server лишними расчётами. 

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

Отлаживать код на сервере сложнее, возможности Transact-SQL на много слабее, чем любой нормальный язык и тут даже нечего сравнивать с C#. Зачем извращаться писать код на Transact-SQL, когда можно использовать все прелести .NET? 

Я использую хранимые процедуры и функции только при создании отчетности. Вот тут я люблю, чтобы все выполнялось на сервере - просто запускаешь SQL запрос и в результате получаешь готовый отчёт, который не должен дополнительно обрабатываться на сервере приложений. 

Для меня задание этой компании указало на то, что там явно слишком сильно используется Transact-SQL. Я не говорю, что это не правильно, я просто не люблю такое и привел свои доводы в этой заметке. Поэтому я не стал выполнять задание. Возможно я не прав, и там SQL используется не так уж и сильно, как я подумал. 

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым