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

Я бы рекомендовал подходить к таким вопросам с точки зрения постановки и целесообразности функциональности. Клиент может желать все, даже не имея представления, зачем ему это нужно. "Шоб было круто" - обычная практика обоснования таких вещей. У меня одного друга "обязали" сделать такое же, он затратил уйму сил и времени на это, оказалось, что во первых может раз в год этим кто и воспользуется, во вторых смотрели только кто последний изменил запись - оно и понятно, обычно людей интересует какая сволочь изменила цифру и теперь не сходятся отчеты и им не особо интересно копаться и смотреть, что было до этого раньше. Для таких случаев полей с DEFAULT на CURRENT USER, LAST USER, CURRENT TIMESTAMP и TIMESTAMP как раз хватает вполне достаточно. Другое дело, когда версионность записей необходимо хранить для проведения сторнирующих расчетов, где могут вестись пересчеты задними числами и необходимо на указанный момент времени учитывать в расчетах информацию, актуальную именно на сторнируемый период. Однако таких данных в системе не так много и обычно к таким таблицам реализуют дополнительные таблицы, в которых хранятся старые версии изменившихся полей, для которых важна версионность.

Что конкретно по Вашему решению из критики:
1. Реально придется вложиться на трудозатраты написания триггеров, код которых будет не слабым (все поля логировать позаписно)
2. Система тут же просядет - каждая операция изменения только одной записи будет плодить в такую табличку кол-во записей, равное кол-ву логируемых полей. Увеличиться нагрузка на лог, появятся лишние блокировки на эту таблицу, которые будут мешаться при одновременной записи множества сессий, начнет стремительно расти размер БД и прочие радости жизни.
3. Толку от такой таблички - как от козла молока. Вряд ли будет удобно пользователям смотреть изменения по полю, они захотят увидеть одной записью изменения документа (всех полей записи), запросик на получение этого тоже не будет отличаться легкостью реализации и скоростью выполнения.

Из всех пунктов вытекает вопрос - для чего нужен подобный изврат ? Пользователи просто хотят себя чувствовать себя богами и видеть кто что и когда менял или же предполагается какая то аналитика (не представляю правда, что с этого можно проанализировать, разве что кто больше работает с теми или иными документами) ?

iLLer
О-о-о, какая знакомая задача!!!
Элементарно! Только не ручками надо писать эти триггеры, вот и все.
Я таким механизмом сделал систему репликации. Да простят меня сторонники
встроенной в АСА репликацией, меня она не устроила по определенным причинам.
И эта реп.система гораздо гибче встроенной.
Триггеры создаются по шаблону, из системных таблиц выуживаются все нужные
данные и генерятся триггеры. Изменения в производительности не заметил
вообще. Поскольку операция вставки, то на это времени нужен минимум, а
триггеры только и делают что вставку. Так что производительность не
страдает.
Зачем Вам тогда платная ASA. Взяли бы бесплатный FB, там тоже "легко" можно репликацию сделать. По сабжу - Вы наверное не в курсе, что у ASA еще одна репликация есть - MobiLink, которая именно то, что Вы описали и делает, причем делает качественно и надежно и с возможностью расширения функциональности через C#/Java и поддержки протокола передачи собственных сообщений через механизмы репликации . Так что остается только удивлятся, зачем было делать свой велосипед, обе репликации ASA абсолютно покрывают все потребности, я еще не видел задач, которым бы они не соответствовали.

Однозначно не поймут - самопальные велосипеды это всегда зло, даже если оно и когда то оправдано

Alexxx2783 Уже оффтопик пошел
В принципе нет - идет обсуждение различных видов велосипедов. Но в принципе согласен - если есть желание пообсуждать достоинства и недостатки ASA репликации, то стоит завести новый топик.