protector
Talen
А вот FireBird...
В моем случае когда он загнется? на скольки тыс. записей?
Структура базы простая будет: справочники артикулов, юзверей,... и шапка документа + его содержание. Остатки по ним посчитать
Если нет навороченных OLAP запрсов - то не загнётся никогда. Ни при каких оъёмах. Для OLAP со сложными агрегатами по моим прикидкам лучше не работать с таблицами > 50 000 000 записей.
Posted via ActualForum NNTP Server 1.1
Вы как то странно оцениваете мощность СУБД. Любая СУБД может работать с сотнями миллионов записей в одной табличке, используя для эффективности индексы, кэширование и другое. Однако не все СУБД могут эффективно справиться с запросом, в котором указанны соединения множества многомиллионных таблиц и аггрегациями - их оптимизаторы просто не справляются с эффективным построением плана запроса и в итоге выполнение запроса растягиватся на многие часы работы. Даже такой примитивный запрос:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SELECT t1.Field1, Count(DISTINCT t2.field2) AS count_field2
FROM Table1 t1 // 1 000 000 зап.
INNER JOIN Table2 t2 // 10 000 000 зап.
ON t1.field1 = t2.field1
WHERE t1.type IN ( // совпадение на 1 000 зап.
SELECT t3.type
FROM Table3 t3 // 100 000 зап.
INNER JOIN Table4 t4 // 200 000 зап.
ON t3.field4 = t4.field4 and t4.field5 IN ( 1 , 100 , 1000 ) )
GROUP BY t1.field1
ORDER BY t1.field1, count_field2;
уже даст оптимизатору повод хорошенько пораскинуть мозгами и рассмотреть приличное кол-во планов запросов в поисках лучшего решения и довольно быстро вернуть искомые 1 000 записей, не вешая при этом сервак для других сессий и не отбирая полностью у него все ресурсы. Готовы ли Вы подтвердить, что оптимизатор Interbase с честью выдержит испытания на сложных запросах ? Лично я одним из правилом оценки мощности оптимизатора запросов в дополнение к ручной оценке (просмотр предложенного плана запроса) еще смотрю, сколько вообще планов он перебрал. Чем их больше - тем в принципе лучше, значит СУБД имеет большое кол-во оптимизированных алгоритмов для решение различных задач.
TalenПериод: 2 года, в год по 50 000 документов, в-среднем по 10 строк.
По моему это не те обьемы и не та задача, чтобы вообще задаваться вопросом выбора СУБД.
TalenAccess'ка-то просто дохнет, даже при условии, что все необходимые поля проиндексированы.
С учетом того, что я знаю и видел на Access я могу Вам порекомендовать поставить драйвер "Direct_Hands.sys" - очень помогает :)
