Сообщение Re[10]: Процедуры в БД - это же ужас-ужас!!! от 03.11.2019 7:54
Изменено 03.11.2019 18:53 Cyberax
Re[10]: Процедуры в БД - это же ужас-ужас!!!
Здравствуйте, Sinclair, Вы писали:
S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Тут надо штаны или крестик. Хранимые процедуры в существующих РСУБД, фактически, не оптимизируются никак. Они просто применяются как фильтр к выбранным строкам.
Если у нас процедура должна обработать 100500 тонн данных, то это будет уже не OLAP. А если не OLAP, то стоит ли корёжить архитектуру ради того, чтобы квартальный отчёт будет составляться 10 минут вместо 20? Если же не нужно передавать 100500 тонн данных, то какие проблемы их закинуть на клиента?
S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Тут надо штаны или крестик. Хранимые процедуры в существующих РСУБД, фактически, не оптимизируются никак. Они просто применяются как фильтр к выбранным строкам.
Если у нас процедура должна обработать 100500 тонн данных, то это будет уже не OLAP. А если не OLAP, то стоит ли корёжить архитектуру ради того, чтобы квартальный отчёт будет составляться 10 минут вместо 20? Если же не нужно передавать 100500 тонн данных, то какие проблемы их закинуть на клиента?
Re[10]: Процедуры в БД - это же ужас-ужас!!!
Здравствуйте, Sinclair, Вы писали:
S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Тут надо штаны или крестик. Хранимые процедуры в существующих РСУБД, фактически, не оптимизируются никак. Они просто применяются как фильтр к выбранным строкам.
Если у нас процедура должна обработать 100500 тонн данных, то это будет уже не OLTP. А если не OLTP, то стоит ли корёжить архитектуру ради того, чтобы квартальный отчёт будет составляться 10 минут вместо 20? Если же не нужно передавать 100500 тонн данных, то какие проблемы их закинуть на клиента?
S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Тут надо штаны или крестик. Хранимые процедуры в существующих РСУБД, фактически, не оптимизируются никак. Они просто применяются как фильтр к выбранным строкам.
Если у нас процедура должна обработать 100500 тонн данных, то это будет уже не OLTP. А если не OLTP, то стоит ли корёжить архитектуру ради того, чтобы квартальный отчёт будет составляться 10 минут вместо 20? Если же не нужно передавать 100500 тонн данных, то какие проблемы их закинуть на клиента?