Предлагается обсудить такую штуку.
Сделать способ получения внутри процедуры списка полей, которые из нее
запросили.
Для чего: да чтоб в процедуре видеть, что некая выходная переменная нне нужна
вызвавшему, и соответвенно ее не вычислять.
Пример
есть процедура
CREATE PROCEDURE NEW_PROCEDURE
Привет, Alexandr!
Вы пишешь к All 03 марта 2007:
[Sorry, skipped]
AK в чем достоинства: ненадо изменять количество входных параметров,
AK ненадо где-то формировать p_list, ненадо вызывать функцию pos,
AK механизм универсальный.
Ещё один универсальный решатель
AC
AC Привет, Alexandr!
AC Вы пишешь к All 03 марта 2007:
AC
AC [Sorry, skipped]
AK в чем достоинства: ненадо изменять количество входных параметров,
AK ненадо где-то формировать p_list, ненадо вызывать функцию pos,
AK механизм универсальный.
AC
AC Ещё один универсальный
64-bit Firebird 2.0.x Windows test kits will be available shortly
--
С уважением
Кочмин Александр
Firebird Foundation associate member #257
Можно ли с помощью API узнать домен столбца для запроса?
Что-то при беглом просмотре документации не получилось найти...
Предлагается обсудить такую штуку.
Сделать способ получения внутри процедуры списка полей, которые из нее
запросили.
Для чего: да чтоб в процедуре видеть, что некая выходная переменная нне нужна
вызвавшему, и соответвенно ее не вычислять.
Сейчас можно сделать с помощью дополнительного
Было бы круто уметь создавать агрегатные домены.
Например структурированный адрес (из геонимов) или ФИО.
Довольно много плюсов на мой, косой, взгляд.
1) При создании таблиц, просмотров, процедур, можно вставлять сразу поле
нужного типа и не думать о том, что что-то забыл, лил об именах этих
Ведь у тебя может вызываться процедура из процедуры, а та из процедуры...
И если пользователь, вызывая процедуру верхнего кажет только 1 параметр,
ты не задолбаешься все варианты в процедурах ручками учитывать? ;-)
Может сразу ленивые вычисления реализовать?
Как в хаскеле? ;-)
T
T Ведь у тебя может вызываться процедура из процедуры, а та из
T процедуры... И если пользователь, вызывая процедуру верхнего кажет
T только 1 параметр, ты не задолбаешься все варианты в процедурах ручками
T учитывать? ;-)
T
T Может сразу ленивые вычисления реализовать?
T Как в хаскеле? ;-)
T
ну так если в сервере сделать поддержку, то будет проще перечислять.
Но ленивые вычисления автоматом - это слишком. Мне и if написать не тяжело.
А теперь представь, что параметров в головной процедуре у тебя 18 и она
вызывает ещё 30, а те...
Короче, по моему, фича может пригодиться только
Процедура - это черный ящик для сервера. Вряд ли тебя поддержат.
Подумай о простом объединении с процедуры в запросе и планах. Намного
полезнее.
Дмитрий
А теперь представь, что параметров в головной процедуре у тебя 18 и она
вызывает ещё 30, а те...
Ты не догнал его мысль.
Вторая процедура (у которой 30 параметров) ничего не будет знать про
18 параметров головной. Ибо зачем?
Она (вложенная) будет вычислять только то, что попросит головная.
Не знаю про API, но вот где-то почитать про домены не помешало бы.
Например на ibase.ru
Дмитрий
Было бы круто уметь создавать агрегатные домены.
Например структурированный адрес (из геонимов) или ФИО.
Это не агрегатный, а составной и домен ли? Да и причем тут домен? Что
есть домен в твоем понимании?
Может вычисляемое поле в помощь?
Что скажите, разработчики?
Я лучше закрою уши. :-)))
Из минусов, только минимальное усложнение синтаксиса SQL и вроде как
небольшие переделки API.
Что скажите, разработчики?
Началось весеннее обострение :crash:
Коваленко Дмитрий.
PS. Я только за ...
PSS. Обещаю навещать ... ... ... ... ... ... ... не реже раз в год.
Было бы круто уметь создавать агрегатные домены.
Например структурированный адрес (из геонимов) или ФИО.
Это не агрегатный, а составной и домен ли? Да и причем тут домен? Что
есть домен в твоем понимании?
Может вычисляемое поле в помощь?
Не, он хочет а-ля объекты в одной колонке.
Я
Прикинь, расходная часть накладной будет храниться в той же строчке
Ну, в смысле, табличная часть накладной :sorry:
Коваленко Дмитрий.
KD
KD А теперь представь, что параметров в головной процедуре у тебя 18 и
KD она вызывает ещё 30, а те...
KD
KD Ты не догнал его мысль.
KD
KD Вторая процедура (у которой 30 параметров) ничего не будет знать про
KD 18 параметров головной. Ибо зачем?
KD
KD Она (вложенная) будет вычислять только
D
D Процедура - это черный ящик для сервера. Вряд ли тебя поддержат.
блин... Я ж не заставляю сервер лезти в процедуру.
Пусть он мне просто список полей даст. Дальше я уже сам.
--
С уважением
Кочмин Александр
Firebird Foundation associate member #257
Kovalenko Dmitry пишет:
А теперь представь, что параметров в головной процедуре у тебя 18 и она
вызывает ещё 30, а те...
Ты не догнал его мысль.
Вторая процедура (у которой 30 параметров) ничего не будет знать про
18 параметров головной. Ибо зачем?
Я имел в виду, что головная вызывает ещё 30
DmitryLe пишет:
Не знаю про API, но вот где-то почитать про домены не помешало бы.
Например на ibase.ru
С удовольствием.
Ссылками не поделишься?
T Я имел в виду, что головная вызывает ещё 30 процедур.
T И востребованность их параметров зависит от логики и востребованности
T параметров головной процедуры.
T
T Главное, что при расте количества параметров число их сочетаний растёт
T довольно быстро. И смысл ручного кодирования быстро
Kovalenko Dmitry пишет:
Было бы круто уметь создавать агрегатные домены.
Например структурированный адрес (из геонимов) или ФИО.
Это не агрегатный, а составной и домен ли? Да и причем тут домен? Что
есть домен в твоем понимании?
Может вычисляемое поле в помощь?
Не, он хочет а-ля объекты в
Есть UDF обявленная из kernel32 currentprocessid работало замечатено
на разнах компьютерах. Но вот сегодня столкнулся со этой ошибкой.
Научите в чем дело? Операционка 2000. Раньше такой проблемы не было.
Естественно используется kernel32 из каталога винды.
Alexandr Kochmin пишет:
да нет ничего такого.
Чего только не надумают.
Ну перечитай еще раз первый топик. Я же совсем не то писал. ;)
Я о том, что с ростом числа параметров, и их зависимостей друг от друга,
смысл подобной ручной оптимизации быстро теряется.
Tonal пишет:
Определяем составной домен:
create domain MODIFY as (integer as USER_ID, timectamp as DTIME) not null;
Как-то это все попахивает постреляционностью... Велкам ту D3 SQL Server?
--
Regards,
Ovchinnikov Vasily
ova at tkvc ru
On Mar 3, 7:46 pm, Kovalenko Dmitry [EMAIL PROTECTED] wrote:
Прикинь, расходная часть накладной будет храниться в той же строчке
Ну, в смысле, табличная часть накладной :sorry:
Да, давайте нарушим первую нормальную форму. Самый ужас в том,
что я уже встречал такие архитектурные решения
On Mar 3, 9:22 pm, Ovchinnikov Vasily [EMAIL PROTECTED] wrote:
Tonal пишет: Определяем составной домен:
create domain MODIFY as (integer as USER_ID, timectamp as DTIME) not null;
Как-то это все попахивает постреляционностью... Велкам ту D3 SQL Server?
Да, наследование таблиц, хранимые
Чего только не надумают.
Ну перечитай еще раз первый топик. Я же совсем не то писал. ;)
Я о том, что с ростом числа параметров, и их зависимостей друг от друга,
смысл подобной ручной оптимизации быстро теряется.
Тупишь. При чем тут зависимости?
Список OUT-параметров, которые реально
Прикинь, расходная часть накладной будет храниться в той же строчке
Ну, в смысле, табличная часть накладной :sorry:
Да, давайте нарушим первую нормальную форму.
Там ничего не нарушается. По крайней мере у меня бы не нарушилось.
что я уже встречал такие архитектурные решения - все
KD Кстати мысль. Нафуя список - нужно к OUT-параметрам прикрутить
KD свойство типа RealRequired. А в хранимке пишем
KD
KD if(MyVeryLargeOutParameter.RealRequired)then
KD begin
KD //вычисляем.
KD end
да, точно. Так оно лучше. Я до этого не додумался.
KD PS. Перечитал сообщение... в голову
31 matches
Mail list logo
