iBase.ru Forum

Есть таблица "Типы складских операций" всего 11 записей вида (Ключ(int), наименование(varchar)), рост вроде не предвидится. Надо написать ХП котрая выдаст на выходе список всех накладнух по произвольно выбранным типам (пользователь может выбрать один тип, а может и все 11), в результате чтоб было (номер, дата накладной, контрагент, и тп... еще пяток полей), могут быть как приходные так и расходные.
Собственно дилема в том как передать список типов в ХП либо просто сделать много входных параметров (номер склада, датаОТ, датаДО, тип1, тип2... тип 11) либо сделать временную таблицу вида (ИДСессии, тип_операции), и в процедуру отдавать строку параметров вида (номер склада, датаОТ, датаДО, ИДСессии) в конце процедуры временную таблицу за собой подчищаем.
Вариант 2 универсальней, но надо временную таблицу делать... мож есть "третий путь"?
Сижу как та обезьяна в анекдоте "Ну не могу ж я разорваться"

посмотри, м.б. тебе волшебниковский метод подойдет
http://www.ibase.ru/ibfaq.htm
"как в параметр передать несколько значений (where id in (:param)"

Ещё можно кучу параметров передать одной строкой, в процедуре её парсить. Ещё можно без процедуры по вхере кляухе фильтровать селектом из таблицы или вью. А ещё можно прямо результат процедуры по вхере фильтровать.


-----------------------------------------------------------------------------------
А вы читали доки, потом факи, грабера с кнутом и банду с фаулером ?
Предлагаю грохнуть эту ветку.

sag писал(а):посмотри, м.б. тебе волшебниковский метод подойдет
http://www.ibase.ru/ibfaq.htm
"как в параметр передать несколько значений (where id in (:param)"

Ага, точно, совсем из головы вылетело... Сейчас еще помозгую между созданием таблицы и передачей параметров строкой, наверно сделаю передачу 2 строками в одну на клиенте запихаю приходные типы, в другую строку расходные типы, всего выйдет 5 входных параметров. спасибо за подсказку.

Ivan_Pisarevsky писал(а): Надо написать ХП котрая выдаст на выходе список всех накладнух по произвольно выбранным типам (пользователь может выбрать один тип, а может и все 11)

Такие задачи лучше всего решать динамически формируемыми запросами на стороне приложения, а не с помощью ХП в базе.

Могу показать пример на делфи, если интересно

я бы остановился на варианте с псевдо-временной таблицей...

Видимо понедельник был просто не мой день... Сегодня потратил часок, сделал как в ФАКе через пару строк и тильды в качестве разделителей, нормально заработало.

Такие задачи лучше всего решать динамически формируемыми запросами на стороне приложения, а не с помощью ХП в базе.
Могу показать пример на делфи, если интересно

Ессно все можно динамически, но чем больше динамики, тем дольше отлаживать... Спасибо за поддержку, но состряпать динамически запросец на дельфях я умею

я бы остановился на варианте с псевдо-временной таблицей...

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

Хотя, в принципе можно сделать одну такую псевдовременню таблицу на всю БД одну, ибо структра будет одинаковая для любых подобных выборок, вида
Врем_табл_для _перем_числа_параметров
(ИД_выборки int
ИД_выбираемой_таблицы int)
Как только пользователь навыделял в гриде несколько строк и нажал пипку "состряпать отчет", сгенерировать уникальный ИД_выборки , пройтись по букмаркам и наинсертить во врем таблицу список ключей, потом примерно так отбирать:
select bla_bla
from some_table
where id_some_table in (select ИД_выбираемой_таблицы from Врем_табл_для _перем_числа_параметров where ИД_выборки = :Текущая_выборка)
Это уже просто мысли вслух...

100юзеров * 100 таких запросов в день * 100 записей = 1 000 000 мусорных записей. Если ещё с транзакциями не всё в носе кругло... А потом, войдя во вкус, ещё дорастить автомат, генерирующий такие запросы на косяках ID вместо передачи where по атрибутам...

Merlin писал(а):100юзеров * 100 таких запросов в день * 100 записей = 1 000 000 мусорных записей. Если ещё с транзакциями не всё в носе кругло... А потом, войдя во вкус, ещё дорастить автомат, генерирующий такие запросы на косяках ID вместо передачи where по атрибутам...

Чистить темной ночью, все равно по ночам серверу делать нечего, удалять из псевдовременной таблицы все начисто (хотя если коммиты расставлены не от балды, там не должно ничего быть), бэкап-рестор и к утрецу полный порядок.
Зато нет предела на кол-во передаваемых ключей, строкой слишком длинный список не передашь.