Общая система регистрации базы данных: Сохранение ссылки на другую базу данных.table.column

Question

Мой вопрос:, как связать ссылку, хранящуюся в таблице Log, с частью данных в другой базе данных?

Мы строим систему (Called Fusion), которая будет выполнять определенные ключевые задачи для всех наших других систем, одним из которых является ведение журнала.

Идея состоит в том, что любая другая система сможет использовать Fusion для регистрации конкретной операции.

CREATE TABLE [Log] 
(
[LogID] [int] IDENTITY(1,1) NOT NULL, 
[UserID] [int] NOT NULL, 
[LoggedOn] [datetime] NOT NULL, 
[ReferenceID] [int] NOT NULL, 
[ReferenceLocation] [varchar](250) NOT NULL 
) 

Таким образом, в упрощенной конструкции таблицы выше ReferenceID колонки будет хранить внешний ключ из другого столбца базы данных. Итак, StoryID из базы данных новостей или PersonID из базы данных человека.

Тогда ReferenceLocation сохранит базу данных .table.column местоположение для столбца ReferenceID.

Идея заключается в том, что SQL-запрос может быть записан (с использованием динамического SQL или другого метода), так что ссылочные данные для каждой строки могут быть возвращены при запросе таблицы Log.

Это способ сделать это? Есть ли способ лучше? Должны ли мы переосмыслить аргументы в пользу этого стремления в целом?

Answer 1

Я хотел бы хранить database.schema.table в ReferenceLocation и иметь другое поле для имен столбцов первичного ключа или просто использовать стандартный идентификатор, например:.

CREATE PROCEDURE p_GetFromLog(@LogId int) 
AS 
BEGIN 
    DECLARE 
     @exe nvarchar(1000) 
     ,@RefID int 
     ,@RefTbl varchar(200) 

    SET @RefTbl = SELECT [ReferenceLocation] FROM dbo.[Log] WHERE [LogID] = @LogId 
    SET @RefID = SELECT [ReferenceID] FROM dbo.[Log] WHERE [LogID] = @LogId 

    SET @exe= N'select * from database.schema.table_here WHERE [ID] = refrence_id_here' 
    SET @exe = replace(@exe, 'database.schema.table_here', @RefTbl) 
    SET @exe = replace(@exe, 'refrence_id_here', cast(@RefID AS varchar(12))) 
    EXEC sp_executesql @exe 
END 

Answer 2

Почему бы просто не использовать schema.tablename и rowid?

Answer 3

Здесь очень много «зависит от». Некоторые идеи:

• Добавить столбец для базы данных («DBName», поскольку «база данных» является зарезервированным словом). Полезно, если аналогично именованные объекты находятся в нескольких базах данных (например, если вы должны поддерживать один экземпляр для каждого клиента).

• Добавить столбец для схемы объекта, если (снова) есть похожие объекты, хранящиеся в схемах. Если вы ленивая слякоть (как обычно я), и все в dbo, не беспокойтесь.

• Добавить колонку в качестве приложения. Если несколько вещей используют один и тот же объект, полезно знать, какой из них сделал это на этот раз.

• Добавить столбец для, err, column. Можете ли вы иногда хотеть отслеживать данные отчетливо, а иногда и в совокупности?

• Я бы предположил, что это все для активности на «этом» экземпляре SQL. Я не рекомендую регистрировать активность на одном экземпляре SQL в другом экземпляре SQL, особенно если он размещен на другом сервере.

• Будет ли "UserID" адекватным? Будет ли всегда доступна таблица поиска (или логина)? Можете ли вы получить больше пробега от имени входа в систему отслеживания?

Общая нить в моих идеях - нормализация. Я бы не собирал слишком много данных (например, DB, table, column) в одном столбце, так как - в зависимости от того, что вы хотите получить из ведения журнала - это может сделать последующие запросы очень неудобными.