iBase.ru Forum

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

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

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

P.S. Вопрос изначально был задан здесь: http://www.delphimaster.ru/cgi-bin/foru ... 540771&n=1. Но исчерпывающего ответа пока не получил.

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

как минимум тем, что число идентификаторов для таблиц в базе ограничено. Так что срок жизни такой системы не бесконечен.

kdv писал(а):

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

как минимум тем, что число идентификаторов для таблиц в базе ограничено. Так что срок жизни такой системы не бесконечен.

Это случаем не счетчик изменений таблиц ? В FAQ по Interbase 6 написано про него, что он имеет размер 255.

уж если SP тебе никак не нравятся, то создай одну таблицу на ~100 полей и используй\очищай её.

а еще можно обновится до 2,1 там временые таблицы есть, хотя тебе с таким подходом тоже наврятли подойдут.

SP мне нравятся, но вопрос несколько шире. Как может отразиться на надежности базы данных частое изменение метаданных ? Изменения будут вида - создать объект, поработать, удалить. Будет ли это таблица, хранимая процедура, не важно.

zz 5 писал(а):SP мне нравятся, но вопрос несколько шире. Как может отразиться на надежности базы данных частое изменение метаданных ? Изменения будут вида - создать объект, поработать, удалить. Будет ли это таблица, хранимая процедура, не важно.

Road to hell...

Это случаем не счетчик изменений таблиц ?

НЕТ. я разве неясно написал?
Переходите на FB 2.1, и там временные таблицы хоть обсоздавайте каждую секунду.

Road to hell...

Пятое-десятое . Кто-нибудь мне может объяснить, почему ? Все ответы одного вида "лучше не пробывать", а где аргументы

kdv писал(а):НЕТ. я разве неясно написал?
Переходите на FB 2.1, и там временные таблицы хоть обсоздавайте каждую секунду.

Честно говоря, не совсем ясно. При удалении таблицы счетчик сбрасывается ? Backup/Restore сбрасывает счетчик ? К тому же, цель - обеспечить бесконечность работы системы - у нас не стоит

А переход на FB2.1 в данный момент и в ближайшее будущее, к сожалению, невозможен.

Если таблица одна и та же, то имеет смысл её создать "постоянной", и только чистить данные. Не забывая, конечно, об идентификаторе "экземпляра отчёта", чтобы обеспечить многопользовательскость работы.

Если создавать таблицы нужно всё время разные - то ИМХО нужно менять философию построителя отчётов. Даже с учётом возможностей 2.1 по временным таблицам.

zz 5 писал(а):

Road to hell...

Пятое-десятое . Кто-нибудь мне может объяснить, почему ? Все ответы одного вида "лучше не пробывать", а где аргументы

Аргументы в документации, например кэширование метаданных.

Если таблица одна и та же, то имеет смысл её создать "постоянной", и только чистить данные. Не забывая, конечно, об идентификаторе "экземпляра отчёта", чтобы обеспечить многопользовательскость работы.

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

Честно говоря, не совсем ясно. При удалении таблицы счетчик сбрасывается ?

похоже, у Вас как-то с чтением плохо. я про идентификаторы таблиц - rdb$relation_id. Для которого используется системный генератор. И который разумеется никак не сбрасывается ни при удалении таблицы, ни при BR. Вас как-то заклинило на счетчике версий форматов (вариантов структуры таблиц), который тут вообще ни при чем.

kdv писал(а):похоже, у Вас как-то с чтением плохо. я про идентификаторы таблиц - rdb$relation_id. Для которого используется системный генератор. И который разумеется никак не сбрасывается ни при удалении таблицы, ни при BR.

Понятно, начал копать в эту сторону. Во-первых, поле rdb$relation_id имеет тип SmallINT, т.е. может иметь всего 32'767 значений. Во-вторых, поставил следующий эксперимент. Запомнил номер последного ID (Max(rdb$relation_id)). Написал скрипт, который создает и удаляет 10'000 таблиц. Пару раз прогнал. Выяснил, что ID увеличивается для каждой новой таблицы на одно значение. Но ! Затем выполнил простой запрос создания одной таблицы и посмотрел ее ID. Оказалось, что ID новой таблицы принял значение не Max(ID) + 1, а гораздо более меньшее. Если после скрипта ID был равен 23K, то новая созданна я таблица имеет ID = 1319. Непонятно, где же "собака зарыта" ?