Создайте UDF представления с табличным значением для представлений в другой БД - PullRequest
Новая
       12

Создайте UDF представления с табличным значением для представлений в другой БД

0 голосов
/ 21 января 2020

В другой БД есть ~ 10 представлений, из которых мне нужно получить данные. В настоящее время моя команда передает строку в команду SQL EXEC. Я знаю, что есть лучший способ. Локальная БД содержит данные для устаревшего программного обеспечения, а «другая» БД содержит данные для нового программного обеспечения. Мы объединяем два. Более новое программное обеспечение также создает новую БД для каждого клиента / проекта с идентичными структурами.

Оптимально, я хотел бы создать триггеры для каждого из 10 представлений, которые вставляются в уже существующую таблицу в нашей локальной БД. Моя проблема здесь в том, что представления могут иметь только триггеры INSTEAD OF, и мне понадобится триггер AFTER, чтобы БД по-прежнему работала нормально.

Другой метод, который я рассматриваю, - это UDF с табличным значением. Мой самый большой недостаток в этом состоит в том, что устаревшее программное обеспечение использует уникальные идентификаторы, тогда как новое программное обеспечение не (для полей, которые я выбираю).

Есть ли другой способ, которого я не вижу, или какие-либо улучшения эти методы?

Я опубликую псевдо-пример ниже - у меня есть одна БД с таблицей (например), называемой car-parts, а также набор хранимых процедур и представлений, которые используют указанную таблицу. В другой БД у меня есть 10 таблиц, каждая из которых представляет автомобильную деталь (двигатель, глушитель, сиденья и т. Д. c.), Которую необходимо объединить и использовать аналогично таблице автомобильных деталей. Для каждого нового производственного продукта программное обеспечение для моделирования создает новую БД для этих 10 таблиц.

Сейчас мы делаем что-то вроде 

DECLARE @SQLCmd varchar(max) = '
    SELECT * FROM [''' + @DynamicTableName + '''].[dbo].[Engine] 
    UNION 
    SELECT * FROM [''' + @DynamicTableName + '''].[dbo].[Muffler]
    ... '
EXEC(@SQLCmd)

Идентификаторы в деталях машины могут быть уникальными, тогда как идентификаторы в 10 таблицах могут не совпадать, поэтому предположим, что их нельзя использовать.

1 Ответ

0 голосов
/ 29 января 2020

Так что я поставлю наше решение здесь на случай, если какая-нибудь бедная душа окажется в подобной ситуации. Примечание: это не единственный способ справиться с этим, просто способ, который мы решили использовать.

Мы закончили тем, что создали хранимый профессионал c, чтобы извлечь все данные из 10 таблиц на Dynami * 1017. * БД. Этот pro c вставляет указанные данные во временную таблицу, которая создается "родительским" хранимым pro c, которому нужны данные для объединений и еще много чего. Это выглядит примерно так -

Хранимая процедура для родителей 

CREATE TABLE #DynamicData
( 
    ID UNIQUEIDENTIFIER,
    Name varchar(50),
    ...
)

EXEC GetDynamicData @Params=@Params

SELECT * FROM #DynamicData
    JOIN LocalTable on ...

Хранимая процедура для детей 

DECLARE @DatabaseName varchar(50)

SELECT @DatabaseName = DatabaseName
    FROM Project A 
    JOIN Users U on A.UID=U.Project
    where U.EmailAddress = @CurrentUser

DECLARE @SQLCmd varchar(max)=
    'SELECT UID AS ID, Name ... FROM 
    (
        SELECT UID, Name, ... FROM [' + @DatabaseName + '].[dbo].[View1]
        UNION
        SELECT UID, Name, ... FROM [' + @DatabaseName + '].[dbo].[View2]
        UNION
        ...
    ) Items'

INSERT INTO #DynamicData EXEC @SQLCmd

Большая выгода таким образом, столбцы «затвердевают» к тому моменту, когда они попадают в родительскую хранимую процедуру. В Child они просто строки, поэтому нет предложений, ошибок компиляции и т. Д. c. Редактировать вещи в «Ребенке» может быть довольно сложно, но если у вас есть solid представление о том, какие столбцы вы ищете.

...