таблица ссылаеться на саму себя(дерево)
надо вставить узел , который ссылкаеться на самого себя (ПК = ВК)
я просто не знаю как проверить, поэтому хочу уточнить у знающих.

если одной транкзанкцией вставить строку, получить айди, и сделать апдейт - можно ли быть увереным, что ивент который систематически стартует, и ищет узлы помеченые для удаления(ВК -НУЛЛ) не увидит этой вновь созданой записи?. а то вроде не видит, но мало ли...

ЗЫ
может есть лучше способ вставки такой.

ЗЫЗЫкод будет офромляться ввиде хранимки

ScareCrow,

дык ПК - автоинкремент :)

а в мускле в отличии от других СУБД тригер бифо - не видит значение автоинкремента, а в тригере афтер уже позно.

:)

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

ЗЫ так сделал чисто потому что перенести в хранимку подобные действия трудно. и юзер и папка имеет хешированые и шифрованые поля, зависящие от величин, которые вообщето даже не сохраняються.

тоесть счас логика такая, модель = потомок ОРМ знает про эти тонкости, и генерирует хеши, и шифрует. Да, можно чтобы это база делала... но поко что политика партии - не переносить шифрование дешифрование в базу.

типо чтоб нагрузку добавочную не давать... мускл на больших тоблицах вешаеться если строки соединяешь...вот там один дамп на таблицах с записями сотни милионов.
сначала был вариант, что мускл соединяет из джоина 5 полей из обоих таблиц, это по времени чорти что... пришлось дамп грузить в файл, и потом седом по файлу прошолся, и поклеил как надо строчки...(что интересно, тормоза сделать подобное на пхп для файла, быстрее чем мусклом, но всёравно сед с отрывом обрабатывает подобное. и чем длинее файл дампа, тем отрыв сильнее.)

подозреваю если его шифрованием заставить заниматься, быдет ещо медлене