Общая система ведения журнала базы данных: хранение ссылки на другой файл database.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 будет хранить местоположение database.table.column для столбца ReferenceID.

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 3

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