protector
Talen

А вот FireBird...
В моем случае когда он загнется? на скольки тыс. записей?

Структура базы простая будет: справочники артикулов, юзверей,... и шапка документа + его содержание. Остатки по ним посчитать

Если нет навороченных OLAP запрсов - то не загнётся никогда. Ни при каких оъёмах. Для OLAP со сложными агрегатами по моим прикидкам лучше не работать с таблицами > 50 000 000 записей.



Posted via ActualForum NNTP Server 1.1
Вы как то странно оцениваете мощность СУБД. Любая СУБД может работать с сотнями миллионов записей в одной табличке, используя для эффективности индексы, кэширование и другое. Однако не все СУБД могут эффективно справиться с запросом, в котором указанны соединения множества многомиллионных таблиц и аггрегациями - их оптимизаторы просто не справляются с эффективным построением плана запроса и в итоге выполнение запроса растягиватся на многие часы работы. Даже такой примитивный запрос:
уже даст оптимизатору повод хорошенько пораскинуть мозгами и рассмотреть приличное кол-во планов запросов в поисках лучшего решения и довольно быстро вернуть искомые 1 000 записей, не вешая при этом сервак для других сессий и не отбирая полностью у него все ресурсы. Готовы ли Вы подтвердить, что оптимизатор Interbase с честью выдержит испытания на сложных запросах ? Лично я одним из правилом оценки мощности оптимизатора запросов в дополнение к ручной оценке (просмотр предложенного плана запроса) еще смотрю, сколько вообще планов он перебрал. Чем их больше - тем в принципе лучше, значит СУБД имеет большое кол-во оптимизированных алгоритмов для решение различных задач.

TalenПериод: 2 года, в год по 50 000 документов, в-среднем по 10 строк.
По моему это не те обьемы и не та задача, чтобы вообще задаваться вопросом выбора СУБД.

TalenAccess'ка-то просто дохнет, даже при условии, что все необходимые поля проиндексированы.
С учетом того, что я знаю и видел на Access я могу Вам порекомендовать поставить драйвер "Direct_Hands.sys" - очень помогает :)

Vadim_Maximov Talen Vadim_MaximovPersonal Oracle

Оракл штука хорошая, только мне кажется, что это "из пушки по воробьям" будет
Воробьи иногда вырастают в соколов, а бывает даже, что и в страусов.
Просто у меня был такой опыт - писал заказную системку для небольшого бара-ресторана. Сначала реализовал все на Paradox'е. Через какое-то время понял, что не справляется, т.к. "системка" разрослась и стала уже напоминать "систему". Переписал все на Personal Oracle и возрадовался...
Не согласен с Вашим сравнением. Вы писали на файл-серверной технологии и естественно из за этого пострадали. Писали бы на клиент-сервере и проблем бы изначально не было. Так что Оракл тут совершенно не причем - Вы просто неправильно выбрали инструментарий и не исследовали задачу.