Встроенный SQL в производительности RPGLE в обновлении

При обновлении полей даты/времени в файле с использованием встроенного SQL в программе RPGLE я могу использовать либо CURRENT_DATE/CURRENT_TIME, либо сохранить текущее значение даты/времени в переменной хоста. И использовать этот хост для назначения.

Теперь интересно, какой способ быстрее? Или это не имеет значения?

exec sql
  update testpf
  set t1date = CURRENT_DATE, t1time = CURRENT_TIME
  where t1key = someValue;

or

dcl-s date date;
dcl-s time time;
exec sql
  set :date = CURRENT_DATE;
exec sql
  set :time = CURRENT_TIME;
exec sql
  update testpf
  set t1date = :date, t1time = :time
  where t1key = someValue;

Примечание: Это все пишется "на лету"! Но я надеюсь, вы понимаете, что я имею в виду

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


person Radinator    schedule 11.03.2019    source источник
comment
Оба будут довольно быстрыми версиями, одна из них приятнее для глаз.   -  person danny117    schedule 12.03.2019


Ответы (4)


Я думаю, что на ваш вопрос нет простого ответа, на самом деле, если вы ищете информацию о переменной хоста, IBM также не даст вам быстрого ответа, посмотрите здесь:

Переменным хоста требуются коэффициенты фильтрации по умолчанию. Когда вы связываете статический оператор SQL, содержащий переменные хоста, Db2 использует коэффициент фильтрации по умолчанию, чтобы определить наилучший путь доступа для оператора SQL. Db2 часто выбирает путь доступа, который хорошо работает для запроса с несколькими переменными хоста. Однако в новом выпуске или после применения обслуживания Db2 может выбрать новый путь доступа, который не будет работать так же хорошо, как старый путь доступа. Во многих случаях изменение путей доступа происходит из-за факторов фильтрации по умолчанию, что может привести к тому, что Db2 оптимизирует запрос другим способом.

person Nifriz    schedule 12.03.2019

Если вы собираетесь использовать регистры CURRENT_DATE и CURRENT_TIME, я полагаю, было бы лучше просто использовать их в операторе SQL, который в них нуждается. Ваш второй пример включает три запроса к базе данных, а первый пример включает только один. Поэтому я подозреваю, что первый будет работать лучше, поскольку все три имеют одинаковые (получить этот регистр) накладные расходы, но у второго накладные расходы на вызовы трижды, а не один раз.

Кроме того, первое просто легче читать (самое важное соображение, ИМО, если это не так). То есть нет необходимости оптимизировать, если вам это не очень нужно. Конечно, если бы я хотел получить текущую дату и время в RPG, я бы не использовал для этого SQL, а использовал бы встроенную RPG, например %date() или %time() ;-)

Изменить. Здесь есть несколько соображений, не связанных с производительностью. Если вы хотите, чтобы дата/время были одинаковыми для всех строк, для всех обновлений, вам придется записывать дату и время заранее. Если вам нужна фактическая дата и время обновления, вам нужно будет использовать регистры. Одна приятная вещь, которую делает SQL, заключается в том, что если вы используете CURRENT_DATE, CURRENT_TIME или CURRENT_TIMESTAMP или какую-то смесь этих нескольких раз в одном операторе SQL, все обновленные строки будут иметь одну и ту же дату, время и отметку времени для данного выполнения SQL. утверждение.

person jmarkmurphy    schedule 11.03.2019

Мои два цента. Знаете ли вы о столбце отметки времени изменения строки в IBM i? Они описаны в https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/sqlp/rbafysqlprcts.htm?

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

person Daniel Lema    schedule 11.03.2019

Лично я бы использовал первый вариант. Код проще, и я не могу представить, что будет значительная разница в производительности.

Единственный раз, когда я бы выбрал второй вариант, - это если иногда может потребоваться дата, отличная от системной даты (например, UDATE).

person jtaylor___    schedule 13.03.2019