> Моё отношение к прогрессу: > 1. Докажи, что без этого чего-то сделать невозможно. > 2. Не смог - докажи, что это даёт существенное увеличение > производительности СЕРВЕРА, а не программиста, в достаточно широком > классе задач,
Гм... может я в чем-то ошибаюсь, но я вижу, что весь мир движется по направлению к облегчению жизни именно программистов, читай людей, а не "серверов". Другое дело, что кто-то может переусердствовать, не будем упоминать в суе кто именно :) К примеру, добавление Олегом в Yaffil встроенных функций демонстрирует гуманный подход к людям в своем лучшем виде. Ведь без них же можно смело обойтись, сделав реализацию в UDF! Однако, как приятно и УДОБНО, что этого делать не надо. Я уже не говорю про экономию времени и сил на сотворение _элементарных_ UDF и их неминуемую отладку, что еще не гарантирует, что багов в результате не будет. Вопросы разного рода логирования и репликации были, есть и, смотрю, долгое время еще будут актуальными в нашем народном сервере. Потому как все "лучшее" серверу, а программистам - в очередь на курсы по проктологии :) Еще надо смотреть с точки зрения сложности реализации фичи в сервере и на соотношение стоимость реализации/польза на выходе. К слову, никто из Чапаев не высказался по этому вопросу. И если там делов "на две строки и на бутылку пива", то польза от CURRENT_TABLE будет многократно больше (плюс уже куча всяких CURRENT_XXXXXXX имеется), не смотря, что могут сделать только к версии 4.0. Если там гиенна огненная это делать, тогда совсем другой разговор и CURRENT_TABLE этого просто не заслуживает. > а не в той личной проктологии, в которую ты сам себя > загнал, забивая болт на правила проектирования. На правила проектирования и проктологические аспекты тоже может быть разное видение. К примеру, вместо того, чтобы, допустим, в коде каждого триггера (отдельного) просто повторить ОДНУ строку: EXECUTE PROCEDURE (CURRENT_TABLE, NEW.ID/OLD.ID, <тип операции>); и при этом НЕ ТРОГАТЬ логируемые таблицы вообще на каком-либо уровне, включая логический (это значит, что можно добавить/изъять или включить/выключить целую функциональную логическую часть системы, что другие части даже об этом _не догадаются_ - обращаю на это внимание отдельно) поступают предложения: - прописывать руками имена таблиц как строковые константы (вспоминаем Коваленко, когда он говорил, что где-то забыл триггер сделать, здесь можно просто сделать ошибку в букве) - добавления доп полей в таблицы (размазывать логику логирования по всем таблицам в виде доп полей) - использования DEFAULT полей с именем (в каждое таки надо прописать руками имя таблицы) - упоминание про GET/SET CONTEXT - кто-то еще призагнул про какие-то ветвления по имени таблицы, вообще не разобравшись в сути треда (это уже проблемы индейцев и где-то таки может быть удобным) И это все менее проктологичнее одной строки кода, плюс сделанной автоматически? (конечно, при прочих равных условиях) Чем плохо, когда пользователь просто пометит чекбокс на клиенте в сетке напротив имени таблицы, а в это время для этой таблицы _на стороне сервера_ сгенерится триггер на поддержку логирования? Стоимость решения на клиенте - стремится к 0. Т.е. просто включить/отключить чекбокс с коммитом. Т.е. вообще ничего, по сути. Вместо этого мне надо делать на клиенте код генерации триггеров? Это дешевле? Он у меня есть, но в данном случае, я хочу, чтобы даже его не было (в общем, это не относится к CURRENT_TABLE). > 4. Ничего доказать не смог - иди в сад со своими хотелками. Голос из сада :))): имхо, если в триггерах кому-то надобится иметь непосредственное название таблицы, то CURRENT_TABLE уже автоматически лучше, со всеми вытекающими, чем прописывать 'MY_TABLE_NAME' в каждом разе. И это все просто БЕЗОТНОСИТЕЛЬНО к разного рода проктологическим приемам.
