Настройка нескольких переменных SQL Server

#sql #sql-server-2005 #tsql

#sql #sql-server-2005 #tsql

Вопрос:

У меня есть 7 разных хранимых процедур, которые принимают ряд параметров и вставляют данные в 7 разных таблиц.

Сейчас я создаю основную хранимую процедуру для выполнения этих 7 процедур со всеми необходимыми данными. Все данные, которые им нужны, — это ОДНА таблица (CommonImport).

Должен ли я использовать все необходимые параметры в этой основной хранимой процедуре?

Или

Введите только идентификатор строки, которую необходимо вставить в эти 7 отдельных таблиц, и получите данные непосредственно из таблицы.

Я думаю, что второй вариант является лучшим. НО как мне установить все переменные в основной хранимой процедуре для всех данных из таблицы (CommonImport)?

По сути, как мне установить кучу объявленных переменных в значения из определенной строки в таблице CommonImport?

Спасибо

Ответ №1:

Передача идентификатора:

Преимущество здесь в том, что вы упрощаете все интерфейсы к своим хранимым процедурам.

Это упрощает кодирование. Если вы в конечном итоге вызываете SP из нескольких мест, вам просто нужно использовать один параметр, а не загружать и передавать несколько параметров.

Передача n переменных:

Тогда преимущество здесь в том, что вы «отделяете» свои хранимые процедуры от таблицы хранения.

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

Что лучше:

Я не думаю, что на это есть прямой ответ, это скорее вопрос предпочтений и мнений.

Мое мнение таково, что чем менее тесно связаны вещи, тем лучше. Это более гибко перед лицом изменений.

Я бы сделал это следующим образом…

 CREATE PROCEDURE main_by_variable @v1 INT, @v2 INT, ...
BEGIN
  EXEC sub_part_1 @v1, @v3
  EXEC sub_part_2 @v2
  EXEC sub_part_3 @v2, @v3
  ...
END

CREATE PROCEDURE main_by_id @id INT AS
BEGIN
  DECLARE
    @v1 INT,
    @v2 INT,
    ...
  SELECT
    @v1 = field1,
    @v2 = field2
  FROM
    holding_table
  WHERE
    id = @id

  EXEC main_by_variable @v1, @v2, ...
END
GO;
  

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

Но для удобства вы можете обнаружить, что использование main_by_id является более аккуратным. Поскольку это всего лишь оболочка вокруг main_by_variable, все, что вы делаете, это инкапсулируете один шаг в процессе (получение данных из таблицы).

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

Ответ №2:

Я бы предложил принять все переменные в качестве параметров и определить для них значения по умолчанию, чтобы пользователи SP могли использовать его либо с одним параметром ID, либо с другим параметром as weel, указав их напрямую

 CREATE PROCEDURE MainSP
  @ID int,
  @CustomParameter  varchar(10) = NULL,
  @CustomParameter1 DateTime = NULL,
  ...
  

Таким образом, SP будет довольно гибким

Комментарии:

1. Таблица CommonImport — это просто таблица хранения. Единственными значениями переменных, которые передаются в SP, являются значения из таблицы CommonImport.

2. Кстати, зачем вам нужны 7 отдельных процедур для работы с одной таблицей? Что они делают?

3. Я беру импорт из файла CSV, каждая строка будет проверена и проверена, а затем помещена в таблицу CommonImport. Затем эти данные импортируются в нашу оперативную систему и, в частности, в семь разных таблиц, то есть property, deposit, landlord, tenant и т. Д. Таким образом, Существует семь процедур, которые берут соответствующую информацию из таблицы CommonImport, а затем вставляют в соответствующую таблицу в реальном времени. Кроме того, я решил, что ваш подход лучше всего подходит для параметров, поскольку этот SP может использоваться в других проектах, где CommonImport не является источником данных. Итак, спасибо