Привет всем.
Subj ?

alex_k
>парадокс....
>в смысле плоский файл формата дбф....
Спасибо за участие, но нужно выбрать или MySQL или FireBird...

Там статистика будет некая сниматься раз в 2 минуты. По оценкам до 2 000 000 записей в месяц. Выборки тоже надо будет делать - графики строить кое-какие. Сам я больше к семейству Interbase-овых привычный, но говорят MySQL самый быстрый для таких вещей. Хотя для таблицы порядка 50000 записей я разницы в скорости не увидел. Вообщем, может кто , исходя из личного опыта, что-нибуть скажет по этому поводу . ..

Желательно в пользу Interbase-овых

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

EsKor
>его быстрота сделана за счет отказа от некоторых возможностей. Если не ошибаюсь, то там нет
>хранимых процедур, вложенных запросов и еще чего-то.

Да я вобщем то в курсах, поэтому 3 года назад я выбрал Интербэйс - тогда бесплатный, не очень большой и со многими "взрослыми" вещами (UDF,SP, transactions) , а MySQL мне показался тогда детской игрушкой, не пригодной для более или менее серьезных задач (тогда в нем еще ко всему и union-ов не было, причем в доках доказывалось, что они как и транзакции с хранимыми процедурами на фиг не нужны).

Но в данном случае нужна именно скорость и мне просто интересно настолько ли эта мускульная быстрота (если она вообще будет иметь место) будет заметна, чтобы стоило из-за нее (для данной задачи) отказываться от Firebird.

Конечно можно параллельно вести две базы и потом сравнивать, но как то не хочется . ..

> 2 ляма записей в месяц это ерунда.
В смысле слова "почувствуйте разницу" здесь будут неуместны? :)

>если сложных триггеров не будет. а так,
>даже с индексами будет нормально работать, на приемлемом железе.
Не, тригеров не будет, только парочка индексов и все.

Ладно, рискну использовать Firebird...

Хрен
> Единственный вопрс, потом куда эти данные деваются? Остаются в таблице?
> То есть через через год будет 24 миллиона? А вот на 24 миллионах разница уже
> может быть очень заметна.
Пока для каждого месяца будет своя таблица типа table2003_08. Потом видно будет...

Roman Ignatiev
>А ты давай попробуй FB1.5, он быстрый :))
К сожалению пока не получится. У меня Linux Debian с glibc 2.2, а FB 1.5 под Линукс требует glibc2.3, которая поставляется пока с RedHat/Mandrake-ами. Так что ждем Дебиановского релиза с glibc2.3

А почему не надо по таблицам? Вроде как чем меньше записей в таблице, тем быстрей отработает запрос? Или где?

Roman Ignatiev

Дело в том, что главном образом будут анализироваться данные, полученные в текущем месяце и эти данные желательно получить со скоростью максиально близкой к "мгновенно". Данные же за другие месяцы нужны будут в среднем раз в полгода, а то и в год, причем для отчетности и приемлимая скорость получения таких данных что то типа "в течении дня". Поэтому в данном случае мне кажется целесообразней произвести разбивку по месяцам - по-моему получить выборку в 1000 записей из максимум 2 000 000 все таки несколько быстрей, чем, скажем, 1000 из 24 000 000 , даже если они проиндексированы по дате.