SQL Server: уникальный ключ для пакетной загрузки - PullRequest
1 голос
/ 06 июля 2010

Я работаю над проектом хранилища данных, в котором несколько систем загружают данные в промежуточную область для последующей обработки. В каждой таблице есть столбец «loadId», который является внешним ключом к таблице «загрузок» и содержит такую ​​информацию, как время загрузки, учетная запись пользователя и т. Д.

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

У меня вопрос: есть ли способ избежать необходимости возвращать loadId в исходную систему? Например, я представлял себе, что я могу получить какой-то идентификатор соединения с Sql Server, который я мог бы использовать для поиска соответствующего loadId в таблице нагрузок. Но я не уверен, есть ли в Sql Server переменная, уникальная для соединения?

Кто-нибудь знает?

Спасибо

Ответы [ 3 ]

0 голосов
/ 15 июля 2010

Я предполагаю, что исходные системы записывают / фиксируют вставки в исходные таблицы, и несколько загрузок НЕ выполняются одновременно ...

Если это так, пусть исходная загрузка вызывает хранимый процесс, newLoadStarting (), до запуска процесса загрузки. Этот сохраненный процесс обновит таблицу загрузки (создает новую строку, время начала записи)

Поместите в столбец loadID триггер, который получит max (loadID) из этой таблицы и вставит в качестве текущего идентификатора загрузки.

Для полноты вы можете добавить процедуру endLoading (), которая устанавливает дату окончания и деактивирует эту конкретную загрузку.

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

0 голосов
/ 23 августа 2010

В итоге я выбрал следующий «шаблон» решения, очень похожий на то, что предлагал Маркус:

  • Я создал таблицу со столбцом loadId, значением по умолчанию null (плюс некоторая другая информация аудита, такая как созданная пользователем и созданная пользователем);
  • Я создал представление таблицы, которое скрывает столбцы loadId и аудита и отображает только те строки, в которых loadId равно нулю;
  • Исходные системы загружают / просматривают данные в представление, а не в таблицу;
  • По завершении исходная система вызывает процедуру «sp__loadFinished», которая помещает правильное значение в столбец loadId и выполняет другие записи в журнал (количество полученных строк, дата вызова и т. Д.). Я генерирую это из шаблона, так как он повторяется.

Поскольку loadId теперь имеет значение для всех этих строк, он больше не виден исходной системе и может при необходимости запустить другую загрузку.

Я также организую, чтобы у каждой исходной системы была своя собственная схема, единственное, что она может видеть, и это значение по умолчанию при входе в систему. Представление и sproc находятся в этой схеме, но базовая таблица находится в «промежуточной» схеме, содержащей данные по всем источникам. Я гарантирую, что в соглашении об именах нет коллизий.

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

0 голосов
/ 06 июля 2010

локальная временная таблица (с одним знаком фунта #temp) уникальна для сеанса, выведите туда идентификатор и затем выберите из него

Кстати, это будет работать, только если вы используете то же соединение

...