Я позволил себе малость стасовать текст, чтоб не писать 10 раз одно и то же.
Dmitriy Kovalenko wrote:
> -----------------------------
> Повторяю: польза в том, что в коде
> триггера можно "программно" узнать, для
> какой таблицы выполняется его код.
> -----------------------------
>> Всё-ж таки, что ж эта процедура будет делать? Код, сьестра, код!
>
>
> Да пох абсолютно, что это будет. Причем
> тут код?
> Более того, если бы у меня была
> возможность CURRENT_TABLE, то это я сделал бы
> ЕЩЕ ПРОЩЕ. Так понятно, из-за чего
> вопрос о CURRENT_TABLE снова возник? :)
Нет, непонятно. И всё более и более переходит в жанр "Хачу! Хачу
самолётик и всё! ААААА :((((" Наверное я тупой, но я так и не понял что
тут упрощает Current_Table.
> Не трогать определения (код) таблиц
> (добавление полей в них). Это просто
> триггер. Просто обычный триггер. Самый
> настоящий триггер.
> Только который
> может знать через CURRENT_TABLE на КАКОЙ
> таблице он исполняется.
Я что-то сказал насчёт того, что для логирования нужны
дополнительные поля? Свой стандарт таблиц я показал в ответ на вопрос о
временных метках, к механизмам логирования не имеющих прямого отношения.
То есть они атрибуты как записи, так и лога, и всё. А флаг отключения
триггеров очень удобен для ремонтных работ не мешая юзерам и только-то.
И ещё для некоторых специфических вещей. Например, для того, чтобы при
выполнении в одной транзакции нескольких последовательных связанных
действий над одной записью отправлять в лог только результирующую
запись. Но это мне потребовалось только один раз. Вопрос о суровой
необходимости Current_Table для лог-триггера остаётся по-прежнему
незыблемым постулатом Вселенной. Как я раньше без него обходился?
Наверное всё делаю неправильно :(
>> Хде? Хто? Предлагал?
>> Хде? Хто? Предлагал?
>> Хде? Хто? Предлагал?
>
>
> Перечитай еще раз и выбери по авторам.
> Я ж не с потолка взял, а перечитал все,
> выбирая упомянутые решения.
Ну, кто-нибудь ведь мог предложить и ещё какую-нить хрень. Ты со
мной споришь? Ну вот моим мне в нос и тыкай.
> Кучу CURRENT_XXXXXX сделали? А там нельзя было
> обойтись "с клиента" или десантом с
> Марса? А ввод Емановым универсальных
> триггеров на события? Зачем? И без них
> все было прекрасно...
Вот-вот. Это является одной из причин, почему мой личный интерес к
дальнейшему развитию FB снизился не до уровня плинтуса конечно, но
заметно. Меня, как представителя круга крупных пользующих корпораций,
интересуют:
1. SMP-супер.
2. Администрабельность на уровне IB7 - мониторинг коннектов, возможность
снять запрос/коннект без риска повредить базу, хранение юзеров в базе и
нормальное блокирование всемогущего SYSDBA.
3. Общее повышение производительности.
Именно в такой последовательности приоритетов. А что мы имеем? По пункту
3 есть подвижки в плане новых индексов, оптимизатора, стратегии работы с
мусором. Это хорошо. По пункту 2 - вроде бы надёжный шатдаун (ещё не
тряс как следует) и можно причислить реанимированный nbackup. Негусто.
По пункту 1 по нулям. Зато с самолётиками - хоть залейся.
> Просто я спрашиваю про одно, а
> меня лечат какой-то хренотенью
> совершенно не по теме.
Взаимно.
> Я не выношу на
> обсуждение сейчас механизмы, в которых
> мне понадобился бы CURRENT_TABLE.
Потому что их просто нет. Или они в сфере частных-личных
специфических решений. Ладно, я устал и разозлился, хорош флудить, надо
ещё кое-что сделать сегодня.
--
Regards. Ded.
