она не станет копией справочника. Она станет копией результата отработки рекурсивной ХП

> Ega23 ©   (20.06.08 10:30) [9]
> > Кстати вариант с триггером ИМХО очень перспективный вариант.
> От ситуации зависит. Может быть и перспективным. А может
> - и нет.

Согласен, но я не уточнил что относительно моих задач, где таблица пополняется крайне редко (единичные случаи в месяц), а вот выборка при расчете в основном и "загружает" сервак.

>stud ©   (20.06.08 11:05) [15]
>ну тут наверное типа временная таблица с тими триггерами (есть такое в 2005?) и при >добавлении записи в нее триггер вытаскивает типа "детей", добавляет их в нее и

Вы, извиняюсь, вообще представляете себе, для чего используются триггери и как они работают ?

>получается в общем и целом бред,

вот это уже ближе к истине

>хотя работать будет

Угу, и подвесит нафиг сервер к чертовой матери.

MsGuns ©   (20.06.08 11:11) [19]
в MSSQL в хранимках есть 1 минус, результат не так уж просто объеденить с другой таблицей.

>stas ©   (20.06.08 11:15) [23]
>в MSSQL в хранимках есть 1 минус, результат не так уж просто объеденить с другой >таблицей.

Сами придумали или кто вумный поделился "опытом" ?

MsGuns ©   (20.06.08 11:15) [22]
У меня наоборот вешался, пока не перешли на таблицы.

MsGuns ©   (20.06.08 11:17) [24]
у вас есть простое решение?

> наполняется триггерами, таким образом при выборке используется
> таблица, без всяких функций и рекурсий.

это и есть завуалированная рекурсия, если ты не догадался
только рекурсия наполнения, а не чтения

Правильный-Вася   (20.06.08 11:25) [27]

Читаем жирным
>таким образом при выборке используется
> таблица, без всяких функций и рекурсий.

> Вы, извиняюсь, вообще представляете себе, для чего используются
> триггери и как они работают ?

очень смутно))
есть таблица, в нее запросом добавляется запись с ид узла. далее срабатывает триггер на вставку, который ищет "детей" для добавленной записи, вставляет их в эту же таблицу, опять срабатывает (получается аналог рекурсии) или пардон с триггерами есть другой вариант?


> Она станет копией результата отработки рекурсивной ХП

это в случае если данные из нее после получения удаляются.

> stud ©   (20.06.08 11:32) [29]
> > есть таблица,
>  в нее запросом добавляется запись с ид узла. далее срабатывает
> триггер на вставку, который ищет "детей" для добавленной
> записи, вставляет их в эту же таблицу, опять срабатывает
> (получается аналог рекурсии)


На сколько я понимаю триггер наложен на основную таблицу и перестраивает служебную в которой в упрошенном варианте тригерров нету.

stud ©   (20.06.08 11:32) [29]
Напишу только про Insert
при добавлении записи в основную таблицу срабатывает триггер, который рекурсивно либо каким-то другим способом находит всех родителей только на вставленную запись, и заполняет другую таблицу. Таким образом у нас рекурсия работает, только на корректировку таблицы и только по тем записям которые связаны с редактируемой.
Это повшает производительность и не тянет много ресурсов при выборке, но снижает при корректировке таблицы.

Я всё равно продолжаю не понимать, нафига нужен триггер и особенно - временная таблица?
Если есть такая таблица, которая изменяется крайне редко, но оттуда частые селекты идут - ну и заточи её под селекты изначально. Сделай какой-нибудь AbsoluteLevel и какой-нибудь ChildCount и AllChilsCount (тут можно подумать да в сети почитать).

А временная таблица в данной ситуации - это вообще жесть. В MSSQL их 2 типа - одни с # - на конкретный spid со временем жизни <= времени жизни spid. Второй тип - с двумя ## - в рамках сервера со временем жизни <= времени жизни самого сервера.
При разрыве соединения в первом случае и остановке (перезапуске) сервера во втором - ТАБЛИЦЫ БУДУТ ГРОХНУТЫ.

А в первом случае такая временная таблица будет создаваться для КАЖДОГО КЛИЕНТА.

Ega23 ©   (20.06.08 12:01) [32]
Ты ничего непонял...

триггер+временная таблица такого нет!
есть триггер+постоянная таблица это 1 вариант
есть Multi statement function, которая по своей структуре подразумевает временную таблицу и возвращает ее результат это 2 -й вариант.

> Ega23 ©   (20.06.08 12:01) [32]
> Ты ничего непонял...
>


Я понял всё прекрасно. И вообще, за последние 2.5 года 70% времени программирования серверной части уходило на работу с иерархическими структурами под MSSQL.
Так что не надо мне тут...  :)

аналагично :)

> при добавлении записи в основную таблицу срабатывает триггер,
>  который рекурсивно либо каким-то другим способом находит
> всех родителей только на вставленную запись, и заполняет
> другую таблицу.

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

Чет его знает, как ты умудряешься повесить сервер..
У меня разузлование выполняется на "деревянной" таблице с 5 млн.записей, причем вместо ид-ра используются нативные стринги, а кроме того еще из 5 разных таблиц берутся уточняющие данные (замены, техотход, позаказная расцеховка, наименования и прочий "интерьер"). "Дерево" из 30 000 узлов выгребается за 4 мин. Из 10 000 - за 30 сек. MS SQL 2000

Воистину рыба портится с головы ;)

MsGuns ©   (20.06.08 12:57) [38]
Сколько пользователей юзает одновременно эти деревья?

stud ©   (20.06.08 12:40) [37]
нет.