Re[8]: Процедуры в БД - это же ужас-ужас!!!
От: amironov79  
Дата: 02.11.19 21:22
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Ну, вы же почему-то доверяете базе обрабатывать логику джойнов? Или вы поклонник NoSQL?

S>Почему же вы не хотите доверить базе что-то чуть более сложное?

Доверяю, потому что в моем понимании джойны, выбороки и проекции это не совсем уровень бизнес-логики, это уровень доступа к данным. Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?

S>Ещё раз подчеркну: абстрактных соображений вроде "больше простора" при принятии архитектурных решений лучше избегать.

S>Единственный правильный способ — это для каждого конкретного случая сравнивать конкретные характеристики.

Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.

И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?

А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?

S>Потому что вот предлагаемый вами подход как раз и приводит к неожиданным решениям типа "да я щас подниму результат в джаву и пробегусь по нему регекспом для отбора", которые потом тормозят в продакшне.


S>А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений.

S>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).

Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.

S>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.


Здесь вообще не понял про что речь. Статическая компиляция регулярки?

S>Но данное решение даже в голову не приходит тем, кто думает мантрами типа "логика в базе — это ужас-ужас".


Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.