Вопросы надежности при частом создании/ удалении таблиц
Вопросы надежности при частом создании/ удалении таблиц
Доброго дня, коллеги.
Имеем базу под СУБД Firebird 1.5.4. Часто возникает необходимость получить НД из таблиц, отсутствующими в базе, например, для вывода отчетов, редактирования. Допустим, возьмем следующий вариант: при каждом выпуске отчета в базе данных создается таблица, в нее закачиваются некий объем данных, формируется выборка. После формирования отчета таблица уничтожается.
Чем плох данный вариант ?
P.S. Вопрос изначально был задан здесь: http://www.delphimaster.ru/cgi-bin/foru ... 540771&n=1. Но исчерпывающего ответа пока не получил.
Имеем базу под СУБД Firebird 1.5.4. Часто возникает необходимость получить НД из таблиц, отсутствующими в базе, например, для вывода отчетов, редактирования. Допустим, возьмем следующий вариант: при каждом выпуске отчета в базе данных создается таблица, в нее закачиваются некий объем данных, формируется выборка. После формирования отчета таблица уничтожается.
Чем плох данный вариант ?
P.S. Вопрос изначально был задан здесь: http://www.delphimaster.ru/cgi-bin/foru ... 540771&n=1. Но исчерпывающего ответа пока не получил.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Пятое-десятое . Кто-нибудь мне может объяснить, почему ? Все ответы одного вида "лучше не пробывать", а где аргументыRoad to hell...
Честно говоря, не совсем ясно. При удалении таблицы счетчик сбрасывается ? Backup/Restore сбрасывает счетчик ? К тому же, цель - обеспечить бесконечность работы системы - у нас не стоитkdv писал(а):НЕТ. я разве неясно написал?
Переходите на FB 2.1, и там временные таблицы хоть обсоздавайте каждую секунду.
А переход на FB2.1 в данный момент и в ближайшее будущее, к сожалению, невозможен.
Если таблица одна и та же, то имеет смысл её создать "постоянной", и только чистить данные. Не забывая, конечно, об идентификаторе "экземпляра отчёта", чтобы обеспечить многопользовательскость работы.
Если создавать таблицы нужно всё время разные - то ИМХО нужно менять философию построителя отчётов. Даже с учётом возможностей 2.1 по временным таблицам.
Если создавать таблицы нужно всё время разные - то ИМХО нужно менять философию построителя отчётов. Даже с учётом возможностей 2.1 по временным таблицам.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Аргументы в документации, например кэширование метаданных.zz 5 писал(а):Пятое-десятое . Кто-нибудь мне может объяснить, почему ? Все ответы одного вида "лучше не пробывать", а где аргументыRoad to hell...
Когда-то давно я написал таким образом несколько отчетов, с тогдашним уровнем знаний я просто не видело другого выхода, переписав недавно этот же самый отчет обычным селектом (он получился вестимо довольно громоздким ) получил ускорение на порядок на тех же данных и индексах и теже циферки в отчете.Если таблица одна и та же, то имеет смысл её создать "постоянной", и только чистить данные. Не забывая, конечно, об идентификаторе "экземпляра отчёта", чтобы обеспечить многопользовательскость работы.
похоже, у Вас как-то с чтением плохо. я про идентификаторы таблиц - 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. Непонятно, где же "собака зарыта" ?kdv писал(а):похоже, у Вас как-то с чтением плохо. я про идентификаторы таблиц - rdb$relation_id. Для которого используется системный генератор. И который разумеется никак не сбрасывается ни при удалении таблицы, ни при BR.