Привет.
Расскажите пожалуйста, на сколько мощная СУБД FireBird? Мне интересно знать с базами какого размера она может работать и на сколько шустро? Как она себя ведёт в многопользовательском режиме? Причём не то что пишут на официальном сайте и на официальных источниках в качестве рекламы, а лучше личные мнения тех кто с ней работает.

Какая же мощная? Всего несколько метров инсталяшка   
скажи сколько пользователей, какая БД и другие параметры, мы тебе скажем потянет или нет.

Да пока ещё не знаю какая будет база. Думаю над выбором. Пользователей может быть 10-20 - это максимум, а размер таблиц - да бог его знает. Вот и задаю вопрос, хочу знать что может получиться в результате и чтоб не пришлось переписывать всё на другую СУБД.

ну тогда ничем помочь не могу.
Для некоторых и 100К записей огромная база, а кому-то 10М не очень.
Купи лицензионную промышленную СУБД типа Oracle/MSSQL/DB2/ и т.д. они точно потянут любую БД.
А когда определишься с требованиями к БД, примерное кол-во таблиц, записей по таблицам. Операции в % select|insert/delete/update. Сколько готов платить за СУБД и т.д. вот тогда приходи.

это зависит от кривизны рук   

http://ibase.ru/devinfo/ibfbfeature.htm

там есть пункт "Примеры систем"

Вот это уже интереснее. Ещё бы что-нибудь в таком духе.

у меня стоит сервер fb1.5, 4 базы, в которых некоторые таблицы более 10000 записей. с ней одновременно работает около 25 клиентов, и нормально. Правда сервак выделен специально только для сервера баз.

это маловато, вот если бы миллион записей.....

Провел недавно эксперемент. Взял 2 таблицы 1,3млн записей и начал вставлять одну в другую.
Дошёл до того что в таблице содержится 101млн записей, 71.5 млрд ячеек, на диске она занимает 25ГБ и запрос по подсчёту строк выполняется 22.5мин

        

Индекс есть?

кстати, на сколько мне помнится, то есть разница в подсчёте мужду:


и

ну дак и должна быть разница по стандарту. 
Select count(*) обязан показать общее количество записей. Select count(id) обязан  покказать количество записей у которых id не NULL

Нет. Индекса вроде нет.

Так я и думал. Сделайте и сообщите результаты  

уже не получится
эксперемент закончился, а 25ГБ освобождены

Я вот создал тестовую базу с единственной таблицей из двух полей - числового (первичный ключ) и строкового (100 символов) и заполнил её миллионом записей. Получилась БД размером 120 МБ. Запрос на подсчёт записей выполняется за 1s 391ms.
Вообще в любой БД индексированные чтения и неидексированные отличаются длительностью на 3 порядка   

Это сообщение отредактировал(а) Esperito - 4.4.2008, 13:53

я удалил уже тестовую базу данных
но для эксперементов с индексом начал её восстанавливать
по какому полю вообще лучше всего вводить индекс?

создал индекс по первому попавшемуся полю, но легче то не стало

Это сообщение отредактировал(а) ilya198293 - 8.4.2008, 12:09

Попробуй создать первичный ключ по числовому полю.

Я создал индекс по полю типа double precision
но ничего не произошло по ускорению запроса
может нужно чтоб поле или группа полей были уникальны или может ещё что-то?
на show index реакция нормальная

Первичным ключом делают обычно поле типа INTEGER. Кроме того, эффективности любого индекса зависит от его селективности, т.е. если среди всех значений данного поля очень мало уникальных, эффективность будет крайне низкой.

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

В общем, чем иметь индексы с низкой селективностью, лучше их не иметь вообще.
Да, и вот ещё что. Запрос на подсчёт записей - это не критерий для сравнения с другими СУБД, ибо Firebird и Interbase имеют движки многоверсионных записей, а некоторые другие - нет, тут могут быть неоднозначности... К тому же, мусор в базе и фрагментация таблиц тоже влияет на скорость (после вставки таблиц друг в друга я бы сделал backup/restore).
Лучше сравнивать скорость сложных запросов. Да собственно, в интернете очень много статей по сравнению 
Если есть вопросы, можете задать их монстрам на форуме ibase.ru