Прдолжение истории. Вкратце: в SPL (язык для создания хранимых процедур) приходится работать с многими полями из таблицы, или вообще со всей записью целиком. Это не проблема если в таблице немного полей, но если полей много - возможны ошибки, как синтаксические так и чисто логические. В некоторых СУБД можно объявлять переменную типа запись, основанную на записи таблицы, и работать с этой переменной (и отдельными полями из нее), например так:
Пообщался с техподдержкой, сказал что хочу такой синтаксис в SPL, что упрощает разработку процедур, уменьшает вероятность появления ошибок в коде, и вообще это удобно. Человек из техподдержки написал мне, что создаст запрос (видимо выше) для реализации новой функциональности. Может набраться наглости и попросить чтобы сделали реализацию PL/SQL в Informix ? :)
define row_emp employees%rowtype; ... select * into row_emp from employees where employee_id = Val1;
...
insert into employees values row_emp
...Причем тип row который есть в Informix, таких фокусов не допускает. Т.е. в нем можно обращаться к отдельным полям через точечную нотацию, но например выбрать всю запись из таблицы в переменную без перечисления отдельных полей не получится. Точно также не работает вставка в таблицу из переменной типа row без указания каждого поля. А еще при объявлении такого типа приходится указывать все поля, что ничуть не способствует сокращению размеров кода.
Пообщался с техподдержкой, сказал что хочу такой синтаксис в SPL, что упрощает разработку процедур, уменьшает вероятность появления ошибок в коде, и вообще это удобно. Человек из техподдержки написал мне, что создаст запрос (видимо выше) для реализации новой функциональности. Может набраться наглости и попросить чтобы сделали реализацию PL/SQL в Informix ? :)
1 комментарий:
Хм. Хорошо бы. А ещё полную обвязку Bulk Collection ala PL/SQL - было бы вообще неплохо...
Те же ассоциативные массивы - очень упрощают код в некоторых случаях. Например, когда есть много рассчетов и во многих местах есть обращения к неким параметрам исторической природы (на такую-то дату значение такого-то параметра) - ассоциативные массивы позволяют значительно сократить количество выполняемых запросов к таблице параметров. А значит нагрузку на оптимизатор, словарь и прочая, и прочая. Вроде бы и небольшой запрос к табличке с 1000- записей, но куда приятнее, если обращение за значением в 9 из 10 случаев выглядит как params_array('20120105_AVGSALARYUKR'), а не как (select param_value from param_table where mdy(1,5,2012) between param_begin and param_end and param_code = 'AVGSALARYUKR').
Отправить комментарий