Както посочих в другият ви въпрос , мисля, че тук е подходящ преглед на процеса и сигурността. Това е одитирана база данни, така че никой (особено доставчици на услуги трети страни) трябва да създават таблици във вашата база данни без ваше знание .
Проблемът, който имате, е, както и новата таблица, която се създава, ще трябва да създадете и друга таблица, за да съхранявате одитираните/променените записи, която ще има идентична структура като оригиналната таблица с евентуално час/дата и потребителска колона. Ако доставчик трета страна създава тази таблица, той няма да знае да създаде таблицата за одит, следователно дори и да можете да генерирате динамично своите задействания, те няма да работят.
Невъзможно е да създадете една таблица, която да съхранява всички записи за промени за всички други таблици във вашата база данни, тъй като структурата между таблиците неизбежно се различава.
Ето защо:направете всички заявки за промяна (например доставчиците искат да създадат TableX, те подават заявка за промяна (включително SQL скрипта), обясняваща причината за промяната) на себе си и/или на вашия екип.
Изпълнявате SQL върху тестово копие на вашата база данни и използвате същата структура, за да създадете друга таблица, която да съхранява модифицираните записи.
След това създавате и тествате необходимите тригери, генерирате нов SQL скрипт за създаване на двете таблици и вашите тригери и го изпълнявате във вашата база данни на живо. Давате разрешения на вашия доставчик да използва новата таблица и те си отиват.
Всички са доволни. Да, може да отнеме малко повече време и да, ще имате повече работа за вършене, но това е адски много по-малко работа, отколкото е необходимо, за да опитате да анализирате регистрационните файлове на заявки за повторно създаване на записи, които вече са променени/ изтрийте, или анализирайте двоичния дневник и поддържайте актуална информация с всяка промяна и променете кода си, когато форматът на регистрационния файл се промени и т.н. и т.н.
