2 tygra
>Пример в студию - чего такое не работает, что нужно ждать следующей версии?

Это ты прав, такой пример найти сложно, если уж что-то не работает, то в следующей версии тоже не исправят. Это шутка.

Пример: MSSQL 6.5 - не более 16 таблиц в запросе (сам столкнулся), MSSQL 7, MSSQL 2000 - увеличено до 256 таблиц в запросе. Если нужно еще больше - жди следующей версии.

2 AAron
>Имхо, ограничения подобного плана обсуждались неоднократно и они не интересны. Речь шла об ошибках, котороые реально мешают и жить и их исправление "ожидается в следующей версии".

Все парвильно говоришь, я сам хотел об этом написать в своем посте. А насчет неинтересны, так это только пока сам не столкнешься, а потом очень даже интересно пыхтеть на работе пытаясь решить очередную проблему, вместо того чтоб греться на солнышке на пляже.

Я уже приводил ситуацию с вложенными представлениями, когда нам в техсаппорте мелкософта именно посоветовали ждать следующей версии, а пока менять дизайн БД, чтоб не терять время зря. Хотя у нас все было сделано в полном соответствии с документацией (MSSQL2000), но не работало.

2 tygra
>Ну если бывают запросы, в которых сразу больше 256 таблиц (да и хоть 100) - это проблемы уже не сервера. ИМХО.

Когда делали 6.5 наверное тоже думали что и 16 никогда не встретится. Напомню, что версия MSSQL 6.5 тоже на полном серьезе представлялась и продвигалась на рынке мелкософтом как полноценный конкурент ораклу.

2 AAron
>Возможно я просто не сталкивался с такими ситуациями, но не уверен в производительности системы, где используются view глубокой вложенности и хотя бы 100 join таблиц.

Я привел два разных примера, они не связаны. Во втором примере не было 100 таблиц, их там было штук 20, включая экземпляры. Уровень вложенности view был 6, MSSQL2000 допускает до 16, так что все было сделано по правилам. Зависало напрочь. В техсапорте сказали, что если глубина больше трех, то нужно менять дизайн БД. После трех дней работы снизили глубину до двух или трех, стало чуть лучше, но не сильно.

>разумеется ХП, и возможно временные таблицы. я же говорю, что здесь была порочная практика создания view, в которых есть union, join и т.п. Разумеется такие вьюхи тормозят в сложных расчетах. Да еще на 7.0 иногда планы слетают.

Чепуха, ничего не тормозит при нормальном оптимизаторе. Специально был проведен тест с Sybase ASA 6.5 (а могли взять оракл, просто скрипты не хотелось сильно переписывать), на тех же данных и той же структуре БД отрабатывало по 30 запросов в секунду на хилой машине, для нашего заказчика это было бы выше крыши. И при увеличении количества данных до реальных значений замедления не наблюдалось. Так зачем же мне в MSSQL тратить время и строить сохраненки и временные таблицы, если все замечательно работает и без них, правда в ASA. Я лучше выберу нормальный SQL сервер. И всем советую.

2 tygra
>Если не view, то join-ы :)
View очень сильно тормозят и всегда слетают планы нафиг

Не тормозят совсем. В нашем случае с MSSQL при переходе с 6 уровней вложенности на 3 скорость отработки не увеличилась совсем, просто зависать начинало с чуть большенго числа записей, да и план вроде не изменился, хотя тут я не настаиваю, мог не заметить. Оракл по-моему вообще в начале строит большой развернутый запрос, потом его оптимизирует, поэтому ему до лампочки сколько там представлений. Это как-то можно выключить, но нужно специально конфигурировать запросы и представления.