Jak już wspomniałem w inne pytanie , myślę, że przegląd procesu i bezpieczeństwa jest tutaj w porządku. Jest to kontrolowana baza danych, więc nikt (zwłaszcza zewnętrzni dostawcy usług) powinni tworzyć tabele w Twojej bazie danych bez Twojej wiedzy .
Problem, który masz, oprócz tworzenia nowej tabeli, będziesz musiał również utworzyć inną tabelę do przechowywania kontrolowanych/zmienionych rekordów, która będzie miała identyczną strukturę jak oryginalna tabela, z możliwym czasem/datą i kolumna użytkownika. Jeśli dostawca zewnętrzny tworzy tę tabelę, nie będzie wiedział, jak utworzyć tabelę audytu, dlatego nawet jeśli możesz generować swoje wyzwalacze dynamicznie, nie zadziałają.
Niemożliwe jest utworzenie jednej tabeli, która będzie zawierała wszystkie rekordy zmian dla wszystkich innych tabel w Twojej bazie danych, ponieważ struktura między tabelami nieuchronnie różni się.
Dlatego:złóż wszystkie prośby o zmianę (np. dostawcy chcą stworzyć TableX, przesyłają prośbę o zmianę (w tym skrypt SQL) wyjaśniając powód zmiany) do siebie i/lub swojego zespołu.
Wykonujesz kod SQL na testowej kopii bazy danych i używasz tej samej struktury, aby utworzyć kolejną tabelę do przechowywania zmodyfikowanych rekordów.
Następnie tworzysz i testujesz niezbędne wyzwalacze, generujesz nowy skrypt SQL, aby utworzyć dwie tabele i wyzwalacze, a następnie wykonujesz to w aktywnej bazie danych. Dajesz swojemu dostawcy uprawnienia do korzystania z nowej tabeli i odchodzą.
Wszyscy są szczęśliwi. Tak, może to potrwać trochę dłużej i tak, będziesz mieć więcej pracy do wykonania, ale to o wiele mniej pracy niż jest to wymagane do próby przeanalizowania dzienników zapytań w celu odtworzenia rekordów, które już zostały zmienione/ usunięte lub przeanalizuj dziennik binarny i bądź na bieżąco z każdą zmianą, a także modyfikuj swój kod, gdy zmieni się format pliku dziennika itp.
