авторЮкон действительно позволит написать выборку поддерева одним запросом, но это будет не быстрее, чем в цикле, ну и в тыщи раз медленнее, чем использование альтернативных структур.
Гм, не уверен в этом высказывании. Я находясь в предЮконовском состоянии, т.е. работая на Sybase ASA, которая где то на пару шагов по фичам идет впереди MSSQL могу немного представить себе Юкон :)
Так как в Юконе будет реализован механизм COMMON TABLE EXPRESSION так же, как в Sybase ASA, то следующий запрос:
Будет при выборке гораздо эффективнее, чем цикл и времянки, так как в нем оптимизатор использует специализированные алгоритмы Recursive Hash Join и Recursive Union, да еще с учетом статистики. В тоже время альтернативные структуры конечно будут быстрее, но если вспомнить затраты на их поддержку, то это получается накладным для деревьев малого и среднего обьема.

авторЭто то-же самое, что триггеры на строку - их даже нельзя назвать удобными, за редкими исключениями, но народ только их и будет использовать, когда появится.
Это как их готовить :) Для AFTER операций конечно EACH STATEMENT триггера являются предпочтительней, но для проведения предварительных проверок или дополнительной инициализации полей BEFORE EACH ROW триггера в ASA опять же зарекомендовали себя неплохо, например:
И после такого триггера хоть убейся, но при Field1 = 1 в Field2 всегда будет стринг в верхнем регистре. Очень удобны кстати бывают такие триггера, позволяют иногда убрать логику с ХП, снимая с клиентов обязанность проводить изменения через них и 100% гарантируя правильность содержимого полей таблиц.

Так что Юкон в принципе делает то, что уже давно есть и отработанно в той же ASA. Например, та же поддержка Java не только в кач-ве ХП, но и на уровне сериализации обьектов Java в поля таблицы и работа с ними через SQL в Юконе будет тоже самое насколько я понимаю, но только вместо Java подключат .NET . И не надо говорить, что фичи в Юконе будут бесполезные - очень даже полезные, другое дело что не все ими будут пользоваться правильно, но это по моему к любой СУБД применимо - садомазохистов и велосипедистов всегда хватало и не только в нашей стране :)

авторНо в принципе - откуда возьмётся сильно бОльшая эффективность? Принципиально схема одна - енжин делает циклы по уровням. В ядре они, конечно, быстрее, но не в разы или тем более не на порядки. Единственный сильный ход - это сделать специальные индексы для деревьев (т.е. фактически упомянутые специальные структуры), но этого не сделано хотя-бы потому, что используется механизм COMMON TABLE EXPRESSION, т.е. механизм общего типа, а не специальный на деревья (например, можно было в Юконе сделать отдельный рекурсивный FK-констрэйн, по которому строились-бы такие индексы).
Ну выгода получается только при обработке малых и средних деревьев специальным механизмом оптимизатора HASH, который на основе индекса на Parent_id может построить хэш таблицу вхождений и далее использовать ее. В остальном полностью согласен, специальный индекс не помешал бы. В приниципе в ASA можно заявить о требовании расширения такой функциональности на их специализированном форуме Futures, но для этого должно подписаться достаточно народу, чтобы разработчики ASA поставили себе такую задачу в план расширения версий. Пока насколько я понимаю никто на ASA сверхсложные деревья не обрабатывал, поэтому никто и не просил :) Хотя их форум работает достаточно эффективно и доказательством этому можно привести их ежемесячные патчи, в которых не только исправляются найденные пользователями ошибки (к примеру мои 4 заявленных в конце февраля бага при отработке с довольно специфической логикой скриптов были в апрельском патче уже поправлены), но и расширение функциональности (например ввод OLAP функций и SELECT-ов с поддержкой OVER ... PARTITION BY ... RANGE, насколько я понимаю слизанных у Оракла). Я вот лично все подумываю, что для хорошей жизни мне в ASA не хватает event-ов на DDL операторы (в Юконе вроде как на DDL заявлена поддержка триггеров). Непонятно только как мотивировать такую функциональность и с кем сравнить, если ее еще ни у кого нет (или уже у кого есть ?).

авторТ.е. поймите меня правильно - я не против BEFORE триггеров, я против введения триггеров FOR EACH ROW - это сильно ухудшит общее качество кода, я против VB-лизации SQL-сервера :-).
При этом не забудьте, что триггер FOR EACH ROW - это не дополнительная фунуциональность, это просто чтобы не писать лишние пару строк для курсора.
Мой приведенный пример будет работать один в один так же, как если бы я все сделал курсором в EACH STATEMENT триггер. Фактически ASA перед операцией вызывает BEFORE TRIGGER для каждой записи, подходящей в условие триггера WHEN, любые изменения полей фиксирует в этот набор записей, только после этого делает все проверки CONSTRAINTS (проверки FOREIGN KEY кстати могут отложиться до COMMIT, если для него указана опция CHECK ON COMMIT, полезная фича для деревьев). Далее уже происходит физическая запись изменений в таблицу и потом вызываются AFTER триггера. При таком раскладе если использовать BEFORE EACH ROW триггера только для проверок или модицикаций полей с одной стороны накладных расходов не возникает, т.к. все это происходит на уровне самой ASA, я не организовываю курсоры и т.д. (да и вообще пока ничего не произошло, Inserted и Deleted как таковых физически нет), с другой стороны это позволяет мне например возбудить ошибку до того, как СУБД начнет какие либо операции с данными (это явно лучше, чем обновить миллион записей и потом надумать делать ROLLBACK TRIGGER) или например установить значение в поле для того же Primary Key, хотя с клиента шло NULL, тем самым избежав ошибки и навязав свою логику. Ну а для AFTER триггеров позаписные триггеры понятное дело извращение, тут как раз самое выгодное FOR EACH STATEMENT и обработка всего множества изменившихся записей запросами, а не курсором (про использование DML в BEFORE FOR EACH ROW я вообще лучше промолчу - это из области "Запрос на изменение большого кол-ва данных длинной в жизнь"). Так что исходя из вышесказанного я лично не против TRIGGER BEFORE FOR EACH ROW, я против их неправильного использования :) Нельзя ставить в вину СУБД, что она много умеет - умельцы везде найдутся. Вот например в ASA в UDF разрешено все, что и в ХП (в отличие от MSSQL). Сразу возникает вопрос - "Как много людей постараются написать UDF с использованием курсоров, вызовов ХП или динамическим SQL, а потом использовать эти функции в запросах ?". Ответ будет очевидным - достаточно много, во всяком случае не меньше чем в том же самом Оракле (в процентном отношении конечно общего кол-ва разработчиков этих СУБД). Однако с другой стороны вопрос "Насколько отсутствие в MSSQL BEFORE TRIGGER-ов или в Оракле TRIGGER FOR EACH STATEMENT будет печальным для меня" ответ будет таким: "Печально, гемморно из за лишнего кода, возможно не красиво, но не смертельно, если я хорошо знаю MSSQL или Оракл".

Так что лично я ратую обоими руками как за Оракл, так и за MSSQL. Развивайтесь на здоровье, реализуйте как можно больше возможностей :) Ну а там, где нужны тиражные или удаленные самоадминистрирующиеся кроссплатформенные СУБД с БД средних размеров, с полноценной гетерогенной репликацией (вплоть до off-line) с другими СУБД и мобильными решениями, со скромными аппаратными требованиями и ценой, плюс поддержкой различных наворотов современных СУБД, лучше вспомните о той же Sybase ASA, именно с такими спецификациями она и заявлена. Во всяком случае в забугорье так и есть: консолидированные БД на Ораклах, удаленки и задачи мелко-среднего бизнеса на ASA (с MSSQL такого нет, тут конкурирует удачная реализация MSDE, так что однозначнее выгоднее держать связку MSSQL Enterprise + MSDE). Для информативности даю ссылку на тех описание ASA: http://www.ianywhere.com/downloads/datasheets/SQL_Any_datasheet_0526.pdf , на основе собственных решений и проектов моих коллег по России и СНГ, могу только добавить, что документ не является рекламной брошуркой и соответствует действительности.

авторЗаменить на некий гепотетический групповой триггер BEFORE, в котором можно менять таблицу inserted, то чем он хуже или медленнее? Ведь на каждую из изменяемых строк из тысячи в построчном триггере придётся выполнить запрос, а запрос ведь может быть и сложным.
Ну во первых долгие запросы в BEFORE выполнять нехорошо, операция изменения данных уже запущена, но физической записи в таблицу еще нет. А значит и нет Inserted, т.е. запрос то делать не по чему. Задача в BEFORE максимально быстро сделать прединициализацию операции изменения или обработать ошибки, продотвратив дорогостоящую операцию изменения данных.

Я даже кстати могу точно для ASA 9 сказать, что BEFORE вызываются прямо во время выполнения запроса изменения, т.е. сразу же после проведения блокирования записи, что позволяет при возбуждении ошибки в таком триггере не только отказаться от операции записи, но и предотвратить дальнейшее блокирование данных, что неплохо в тех ситуациях, когда мы изменяем огромное кол-во записей и сразу же наткнулись на ошибку. Думаю Вы согласитесь со мной, что для блокировочника здесь явно перевешивает возможность уменьшения стоимости и длительности блокировок, а не отсутствие BEFORE FOR EACH STATEMENT, для реализации которого ASA пришлось бы сначала все блокировать и только потом решать, все правильно или нет :)

P.S. В доке естественно ничего такого про низкоуровневую работу триггеров BEFORE нет, все проверенно лично мной эксперементальным путем. Хотя как я заметил, если об этих особенностях к ним на форум писать, то в последующем EBF документация по ним аккуратно появляется в BOL. Вот жуки то :)