Доброго дня, коллеги.

Имеем базу под СУБД Firebird 1.5.4. Часто возникает необходимость получить НД из таблиц, отсутствующими в базе, например, для вывода отчетов, редактирования. Допустим, возьмем следующий вариант: при каждом выпуске отчета в базе данных создается таблица, в нее закачиваются некий объем данных, формируется выборка. После формирования отчета таблица уничтожается.

Чем плох данный вариант ?

> Чем плох данный вариант ?


Тем, что при многопользовательском доступе нужно очень аккуратно отслеживать имя таблицы. А то получится, что 2 пользователя разом пытаются создать (удалить) одну и ту же таблицу.

а временные таблицы типа mssql-ых есть? хотя даже если и есть, для отчетов наверное лучше датасеты в памяти использовать.

> а временные таблицы типа mssql-ых есть?


Я аналог искал, но не нашёл. Может плохо искал (я с FB не сильно плотно работал. Так, по-мелочи...)

> Чем плох данный вариант ?

Всем плох во всех смыслах.

> [0] IgorBet   (30.04.08 11:32)
> После формирования отчета таблица уничтожается.

1. Зачем? Почему нельзя просто удалить все записи? Новые писать с признаком текущего юзера, для исключения конфликтов при многопользовательской работе.
2. Вообще пересмотреть логику работы. Псевдовременные таблицы (нормальных в ФБ1.5 нет) почти всегда можно исключить.

> Тем, что при многопользовательском доступе нужно очень аккуратно
> отслеживать имя таблицы. А то получится, что 2 пользователя
> разом пытаются создать (удалить) одну и ту же таблицу.


Эта вопрос решаем, т.к. имя таблицы будет содержать имя пользователя, ее создавшего.


> а временные таблицы типа mssql-ых есть?


Временных таблиц нет, вроде они появились только в версии FB2.


>  хотя даже если и есть, для отчетов наверное лучше датасеты
> в памяти использовать.


по каким параметрам лучше ? я интуитивно сам понимаю, что не самый удачный вариант, но как это объяснить ?

> по каким параметрам лучше ?

> в нее закачиваются некий объем данных, формируется выборка.
закачивается с клиента? (наверняка, т.к. если бы эти данные лежали в таблице на сервере то простой запрос к ним заменил бы "временную" таблицу)
т.е. не будеш вовлекать сервер для чисто локальных действий (формирование отчета).

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

2sniknik

Это все понятно, но решаемо (терпимо). Наиболее сильно интересует  вопрос надежности реализации такого варианта, последствий для файла базы данных.

ну вот, например:
http://ibase.ru/devinfo/ibfaq.htm#1.62

> http://ibase.ru/devinfo/ibfaq.htm#1.62


Я боюсь, что этот материал уже устарел и для Firebird 1.5.4 не актуален. Тем более, в нем говорится, о максимальном количестве изменений одной таблицы, т.е. одну таблицу можно изменить 255 раз ! Я же планирую создавать с нуля таблицы и потом их уничтожать.

Может быть, стоит написать программу-эксперимент, которая, допустим, последовательно создаст и уничтожит порядка 10000 таблиц ?

> Может быть, стоит написать программу-эксперимент, которая,
>  допустим, последовательно создаст и уничтожит порядка 10000
> таблиц ?


СтОит. И запустить её в нескольких экземплярах на одну БД.

> СтОит. И запустить её в нескольких экземплярах на одну БД.

Причем по несколько копий с разных компов одновременно. И под одним юзером (пользователи часто любят запускать несколько копий одной программы)

> Причем по несколько копий с разных компов одновременно.
> И под одним юзером (пользователи часто любят запускать несколько
> копий одной программы)


Само собой.

Данные для этой самой "временной" таблицы откуда "закачиваются", из черной дыры ?

> Я боюсь, что этот материал уже устарел и для Firebird 1.5.4 не актуален

Я как-то в одной публикации, посвященной кросс-табам, привел пример изврата, при помощи которого еще на InterBase 6.0 выходили из положения с невозможностью переменного количества столбцов в хранимой процедуре: на лету создавалась хранимая процедура, строился отчет, а затем эта процедура "грохалась".

Иными словами - игрался я метаданными на лету.

Владислав Хорсун (разработчик Firebird) потом поймал меня в конференции в углу и бил ногами до-о-олго. :)

> Данные для этой самой "временной" таблицы откуда "закачиваются",
>  из черной дыры ?


Перекачиваются из других таблиц.
> Владислав Хорсун (разработчик Firebird) потом поймал меня
> в конференции в углу и бил ногами до-о-олго. :)

Ногами это он потом, а причины он объяснил, почему так не надо ? :)

> Перекачиваются из других таблиц.

Нафига дублируешь данные?


> Ногами это он потом, а причины он объяснил, почему так не
> надо ? :)

Потому что ужас, понятно если бы загонял эти данные в ClientDataset