Как обновить таблицу SQL ежедневными записями?

Question

У меня есть база данных SQL, где некоторые из моих таблиц обновляются ежедневно.Я хочу создать другую таблицу, которая обновляется ежедневно с записями о том, какие таблицы (имя таблицы, дата изменения / обновления) были обновлены.Я также не хочу, чтобы эта таблица становилась слишком большой, поэтому я хочу, чтобы эта таблица сохраняла записи только за последние 31 день.Как мне написать код для этого?

Я уже создал таблицу (tUpdatedTables), но я бы хотел, чтобы эта таблица обновлялась ежедневно и сохранял эти записи в течение 31 дня

Вот какЯ создал таблицу

Select *

Into tUpdatedTables
from sys.tables
order by modify_date desc

Я попытался вставить код «Обновить» для обновления таблицы, но я получаю сообщение об ошибке

update tUpdatedTables
    set [name]
      ,[object_id]
      ,[principal_id]
      ,[schema_id]
      ,[parent_object_id]
      ,[type]
      ,[type_desc]
      ,[create_date]
      ,[modify_date]
      ,[is_ms_shipped]
      ,[is_published]
      ,[is_schema_published]
      ,[lob_data_space_id]
      ,[filestream_data_space_id]
      ,[max_column_id_used]
      ,[lock_on_bulk_load]
      ,[uses_ansi_nulls]
      ,[is_replicated]
      ,[has_replication_filter]
      ,[is_merge_published]
      ,[is_sync_tran_subscribed]
      ,[has_unchecked_assembly_data]
      ,[text_in_row_limit]
      ,[large_value_types_out_of_row]
      ,[is_tracked_by_cdc]
      ,[lock_escalation]
      ,[lock_escalation_desc]
      ,[is_filetable]
      ,[is_memory_optimized]
      ,[durability]
      ,[durability_desc]
      ,[temporal_type]
      ,[temporal_type_desc]
      ,[history_table_id]
      ,[is_remote_data_archive_enabled]
      ,[is_external] 
--Into tUpdatedTables
from sys.tables
where modify_date >= GETDATE()
order by modify_date desc

Сообщение 2714, Уровень 16, Состояние6, строка 4 В базе данных уже есть объект с именем tUpdatedTables.

Answer 1

Я хочу создать еще одну таблицу, которая будет обновляться ежедневно с записями того, какие таблицы (имя таблицы, дата изменения / обновления) были обновлены.

Если это все, что вы хотите, я бы предложил вместо этого просто делать ежедневные резервные копии. Вы все равно должны это делать.

---

Кроме того, вы ищете журнал аудита. Большинство языков и фреймворков имеют библиотеки, чтобы сделать это для вас. Например, paper_trail .

Если вы хотите сделать это самостоятельно, следуйте базовому шаблону paper_trail.

• id как автоинкрементный первичный ключ
• item_type которая будет таблицей или, возможно, чем-то более абстрактным
• item_id является первичным ключом элемента
• event Вы сохраняете создание, обновление или удаление?
• bywho определить, кто внес изменение
• object поле json, содержащее дамп данных
• created_at когда это произошло (используйте значение по умолчанию)

Использование JSON - ключ к созданию универсальной таблицы. Вместо того, чтобы пытаться сохранить каждый возможный столбец каждой возможной таблицы и поддерживать его в актуальном состоянии при изменении таблиц, вы сохраняете дамп JSON строки, используя FOR JSON. Это означает, что таблица аудита не должна изменяться при изменении других таблиц. И это сэкономит много дискового пространства, поскольку позволит избежать появления в таблице аудита большого количества неиспользуемых столбцов.

Например, вот как вы записали бы создание идентификатора 5 из some_table пользователем 23. (Возможно, я не совсем уверен, поскольку не использую SQL Server).

insert into audit_log (item_type, item_id, event, bywho, object)
values(
  'some_table', 5, 'create', 23, (
    select * from some_table where id = 5 for json auto
  )
)

Поскольку таблица аудита не заботится о структуре записываемой вещи, вы используете триггеры вставки, обновления и удаления для каждой таблицы, чтобы записать их изменения в журнале аудита. Просто измените item_type.

Что касается того, чтобы не стать слишком большим, не беспокойтесь об этом, пока это не станет проблемой. Правильная индексация означает, что это не будет проблемой: составной индекс на (item_type, item_id) позволит быстро перечислить изменения для конкретной вещи. Индексирование bywho быстро выполнит поиск изменений, сделанных определенной вещью. Вы не должны ссылаться на эту вещь в производстве. Если да, то, вероятно, требуется другой дизайн.

Разделение таблицы по месяцам также может предотвратить проблемы с масштабированием.

И если он становится слишком большим, вы можете сделать резервную копию таблицы и использовать created_at для удаления старых записей.

delete from audit_log
where created_at < dateadd(day, -31, getdate())