Запросы, планы, оптимизация запросов, ...
Модераторы: kdv, CyberMax
-
zz 5
- Сообщения: 32
- Зарегистрирован: 02 мар 2006, 10:52
Сообщение
zz 5 » 04 май 2008, 10:59
Доброго дня, коллеги.
Имеем базу под СУБД Firebird 1.5.4. Часто возникает необходимость получить НД из таблиц, отсутствующими в базе, например, для вывода отчетов, редактирования. Допустим, возьмем следующий вариант: при каждом выпуске отчета в базе данных создается таблица, в нее закачиваются некий объем данных, формируется выборка. После формирования отчета таблица уничтожается.
Чем плох данный вариант ?
P.S. Вопрос изначально был задан здесь:
http://www.delphimaster.ru/cgi-bin/foru ... 540771&n=1. Но исчерпывающего ответа пока не получил.

-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 04 май 2008, 11:05
Чем плох данный вариант ?
как минимум тем, что число идентификаторов для таблиц в базе ограничено. Так что срок жизни такой системы не бесконечен.
-
zz 5
- Сообщения: 32
- Зарегистрирован: 02 мар 2006, 10:52
Сообщение
zz 5 » 04 май 2008, 11:25
kdv писал(а):Чем плох данный вариант ?
как минимум тем, что число идентификаторов для таблиц в базе ограничено. Так что срок жизни такой системы не бесконечен.
Это случаем не счетчик изменений таблиц ? В FAQ по Interbase 6 написано про него, что он имеет размер 255.
-
Attid
- Спец
- Сообщения: 377
- Зарегистрирован: 14 ноя 2006, 09:58
Сообщение
Attid » 04 май 2008, 12:19
уж если SP тебе никак не нравятся, то создай одну таблицу на ~100 полей и используй\очищай её.
а еще можно обновится до 2,1 там временые таблицы есть, хотя тебе с таким подходом тоже наврятли подойдут.
-
zz 5
- Сообщения: 32
- Зарегистрирован: 02 мар 2006, 10:52
Сообщение
zz 5 » 04 май 2008, 12:30
SP мне нравятся, но вопрос несколько шире. Как может отразиться на надежности базы данных частое изменение метаданных ? Изменения будут вида - создать объект, поработать, удалить. Будет ли это таблица, хранимая процедура, не важно.
-
Ivan_Pisarevsky
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Сообщение
Ivan_Pisarevsky » 04 май 2008, 12:38
zz 5 писал(а):SP мне нравятся, но вопрос несколько шире. Как может отразиться на надежности базы данных частое изменение метаданных ? Изменения будут вида - создать объект, поработать, удалить. Будет ли это таблица, хранимая процедура, не важно.
Road to hell...
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 04 май 2008, 12:41
Это случаем не счетчик изменений таблиц ?
НЕТ. я разве неясно написал?
Переходите на FB 2.1, и там временные таблицы хоть обсоздавайте каждую секунду.
-
zz 5
- Сообщения: 32
- Зарегистрирован: 02 мар 2006, 10:52
Сообщение
zz 5 » 04 май 2008, 12:44
Road to hell...
Пятое-десятое

. Кто-нибудь мне может объяснить, почему ? Все ответы одного вида "лучше не пробывать", а где аргументы
kdv писал(а):НЕТ. я разве неясно написал?
Переходите на FB 2.1, и там временные таблицы хоть обсоздавайте каждую секунду.
Честно говоря, не совсем ясно. При удалении таблицы счетчик сбрасывается ? Backup/Restore сбрасывает счетчик ? К тому же, цель - обеспечить бесконечность работы системы - у нас не стоит
А переход на FB2.1 в данный момент и в ближайшее будущее, к сожалению, невозможен.

-
WildSery
- Заслуженный разработчик
- Сообщения: 1738
- Зарегистрирован: 05 июн 2006, 16:19
Сообщение
WildSery » 04 май 2008, 13:02
Если таблица одна и та же, то имеет смысл её создать "постоянной", и только чистить данные. Не забывая, конечно, об идентификаторе "экземпляра отчёта", чтобы обеспечить многопользовательскость работы.
Если создавать таблицы нужно всё время разные - то ИМХО нужно менять философию построителя отчётов. Даже с учётом возможностей 2.1 по временным таблицам.
-
Ivan_Pisarevsky
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Сообщение
Ivan_Pisarevsky » 04 май 2008, 13:22
zz 5 писал(а):Road to hell...
Пятое-десятое

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

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

) получил ускорение на порядок на тех же данных и индексах и теже циферки в отчете.
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 04 май 2008, 14:38
Честно говоря, не совсем ясно. При удалении таблицы счетчик сбрасывается ?
похоже, у Вас как-то с чтением плохо. я про идентификаторы таблиц - rdb$relation_id. Для которого используется системный генератор. И который разумеется никак не сбрасывается ни при удалении таблицы, ни при BR. Вас как-то заклинило на счетчике версий форматов (вариантов структуры таблиц), который тут вообще ни при чем.
-
zz 5
- Сообщения: 32
- Зарегистрирован: 02 мар 2006, 10:52
Сообщение
zz 5 » 05 май 2008, 10:54
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. Непонятно, где же "собака зарыта" ?