какое макс. кол-во объектов (таблиц, представлений) допустимо в БД Firebird?

Собственно вопрос в заголовке: какое макс. кол-во объектов (таблиц, представлений) допустимо в БД Firebird? ODS 11.2 Проблема в том что при создании большой тестовой БД с некоторого момента начали выдаваться ошибки вида:

unsuccessful metadata update TABLE X_728672481_4_STO Implementation limit exceeded
invalid request BLR at offset 7 table id 3653 is not defined

таблиц в БД - 12384
представлений - 21099
генераторов - 2157
индексов - 16944

Разрешите поинтересоваться для повышения образованности, в какой предметной области надо в одну БД запихнуть столь большое кол-во таблиц и прочей обвязки?

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

воспроизводится всегда на одном и том же шаге итерации?
комит выдается после каждой DDL-инструкции, после n-го шага, в конце скрипта?
последнюю успешную и первую сбойную команду DDL можно увидеть?

arni
воспроизводится всегда на одном и том же шаге итерации?

не пробовал, т.к. сам процесс занимает несколько часов

arni
комит выдается после каждой DDL-инструкции, после n-го шага, в конце скрипта?

по-разному, в основном после каждой команды (использую ОДБЦ драйвер, автокоммит), группы из нескольких представлений создаются в одной транзакции.

arni
последнюю успешную и первую сбойную команду DDL можно увидеть?

скорее всего, создание таблицы (или представления). т.к. сейчас на этой БД проваливается любая команда CREATE TABLE

Ivan_Pisarevsky
в какой предметной области надо в одну БД запихнуть столь большое кол-во таблиц и прочей обвязки?

Область тут обычно ни при чём. Есть разработчики, которые считают, что таблица со ста
тысячами записей это аффигеть как большая таблица и будет тормозить. Поэтому создают
тысячу таблиц по сто записей каждая.

AOT: Теоретический предел - 65535 таблицовьюх, но, судя по всему, где-то там есть баг со
знаковостью.

Posted via ActualForum NNTP Server 1.5

кол-во объектов
база создавалась для проверки производительности софта.

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

кол-во объектов
не пробовал, т.к. сам процесс занимает несколько часов

imho звездеж. уж таблиц насоздавать - никак не несколько часов. или у вас комп жутко тормозной?

а сколько "хранилищ" запихивается в 12 тысяч таблиц, интересно?

кол-во объектов
база создавалась для проверки производительности софта.

вот это ерунда какая-то. производительность на "количестве хранилищ"? Будет практически такая же как на одном. На количестве записей не проверяли производительность?

kdv> производительность на "количестве хранилищ"?
kdv> Будет практически такая же как на одном.

Вообще говоря, это не так, даже если противоположное не факт.
В общем, пока не доказано - не надо делать таких утверждений.

Posted via ActualForum NNTP Server 1.5