Здравствуйте, gandjustas, Вы писали:

V>>Твои представления о том, что в SQL сервере быстро, а что нет, практически полностью противоположны наблюдаемой реальности.
G>Наблюдаемая реальность у всех разная. И зависит от степени кривизны рук.

Т.е. большинство больших промышленных проектов на РСУБД выполнены кривыми руками?
Это ты так решил обидеть РСУБД, что на нём куда ни ткни — везде криворукость?


V>>Под нагрузкой последовательность простых запросов из батча получается ГОРАЗДО более дешевая, чем один тяжелый запрос.
G>Это зависит от того какой собственно запрос и какой ответ.

Это зависит больше от "под нагрузкой" или ты "один в базу стучишься".
Многие вещи, прекрасно работающие в РСУБД в случае одного клиента, резко перестают работать уже при относительно среднем их трафике.
Сотни запросов в секунду для 99.99% наколенных поделок поверх современных РСУБД считается "хорошей нагрузкой".

А чтобы выйти хотя бы на 10 тыс нетривиальных запросов в сек, требуется уже высокая квалификация и целый комплекс мер по избавлению от плюшек РСУБД — избавляемся от внешних ключей, от лишних проверок на уникальность, от проверок на попадание значений в домен, происходит тотальное уничтожение ЛЮБЫХ триггеров, любых пользовательских ф-ий на стороне РСУБД и т.д. и т.п. до бесконечности.

Кароч, вся эта грозная РСУБД превращается в тыкву.

Отсюда возникает правомерный вопрос — а почему бы сразу не взять тыкву? ))


I>>>То есть, индексы все равно остаются. А стало быть эффективный код должен внятно работать с ними. А это значит, что в базу должен уходить качественный запрос, а не абы что.
V>>Define "качественный запрос".
G>1) Выдает нужные данные
G>2) Использует индексы (не читает данные, которые не нужны)
G>3) Cardinality estimator делает как можно меньше ошибок

Я хотел услышать от коллеги, почему в батчах не могут быть "качественные запросы"?