Firebird vs. MySQL - выбор базы.

[diamond_krnl]

Firebird vs. MySQL - выбор базы.

Нужно выбрать базу для сайта на PHP.
Есть огромный опыт с Firebird(interbase), MySQL.

конешно в веб, по привычке, хотелось бы использовать mysql.
НО!!! Сайт будет очень много-структурирован, примерно 100 тысяч записей в таблице с 30 полями, из них 10 - связанные справочники, с активными вставками удалениями, запросами....
В даленейшем будет только наростание количества записей.
Из этого следует что нужна субд посерьёзнее - Firebird как кандидат (безплатная + есть опыт).
НО!!! есть следующие опасение:

Будет ли Firebird в связке с PHP работать достачно быстро - т.е. как быстро происходит конннект к Firebird при запуске PHP скрипта?

Стоит ли игра свечь? может MySQL и так "прожуёт" всё?

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

Спасибо.

 

[neko]

плохо происходит
у нее одни из худших показателей в графе коннекшион оверхед

и вообще за любую функциональность надо платить скоростью

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

 

[diamond_krnl]

Автор оригинала: neko
плохо происходит
у нее одни из худших показателей в графе коннекшион оверхед

наслышен об этом, видимо ib не для веб.

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

речь идёт о хранимых процедурах?
если да то штука не сильно то и нужная в данном случаи.

вообще вопрос более в строну о способностях mysql с большими данными.

 

[neko]

ну вот о чем с такими говорить, объясните мне кто-нибудь...

мужик если для тебя вся разница между mysql и fb заключается в SP
пользуйся чем угодно
хоть скулитом, ты незаметишь все равно разницы
и на скорости коннекта ты тоже разницы незаметишь
но зато будет ой как приятно

-~{}~ 18.02.05 10:14:

мда я тока счас заметил...

опыт с Firebird(interbase)

дядька(бузина), ага

 

[diamond_krnl]

речь идёт о хранимых процедурах?
если да то штука не сильно то и нужная в данном случаи.

neko!!! - читай выще!

мне главное скорость при больших обьёмах данных. всё.
ну соотвественно бесплатность субд.

 

[Sad Spirit]

Автор оригинала: diamond_krnl
Будет ли Firebird в связке с PHP работать достачно быстро - т.е. как быстро происходит конннект к Firebird при запуске PHP скрипта?

Вопрос потрясает своей глубиной. Что, время подключения настолько больше времени собственно выполнения запросов? Или времени работы самого скрипта, в котором, в случае выбора мыскля, будут лежать изрядные куски логики, коим место в базе?

А для борьбы со временем подключения надо юзать pconnect или какой-нибудь внешний (и более продвинутый) connection pool.

 

[si]

А для борьбы со временем подключения надо юзать pconnect

для этого надо иметь свой сервер

или какой-нибудь внешний (и более продвинутый) connection pool

есть линки ?

некоторое время назад я смотрел
http://sqlrelay.sourceforge.net/

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

 

[Sad Spirit]

Автор оригинала: si
некоторое время назад я смотрел
http://sqlrelay.sourceforge.net/

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

Я наугад написал, честно говоря, --- надеюсь, что где-то есть специфичные для Firebird решения, но конкретных не знаю.

sqlrelay сам как-то пытался посмотреть, не очень впечатлён остался...

 

[diamond_krnl]

Автор оригинала: Sad Spirit
Вопрос потрясает своей глубиной. Что, время подключения настолько больше времени собственно выполнения запросов? Или времени работы самого скрипта, в котором, в случае выбора мыскля, будут лежать изрядные куски логики, коим место в базе?

как раз то дело в том что при активной нагрузки на сайт время конекта увеличивается из-за больщого количества коннектов.

А для борьбы со временем подключения надо юзать pconnect или какой-нибудь внешний (и более продвинутый) connection pool.

да стоит посмотреть в эту строну, но нету нормальных, протестированных решений.

открываю карты: пользователь оставляет некие критерии
выбора на обьект + свой контакт (email, sms, icq...), если интресуешее не найдено то поиск "отклыдывается" - т.е. по поступлению новых обьектов происходит поиск отставленных заявок и если чтото найдно - уведовляем по оставленным контактам.

вставка, удаленние, редактирование происходит очень часто и не одним админом сайта а несколько, обьектов ОЧЕНЬ много.

может это параноя? mysql справится?

 

[tony2001]

>может это параноя? mysql справится?
да.

вопреки общепринятому мнению, MySQL "справляется" с таблицами, в которых >10 штук записей.

 

[diamond_krnl]

записей будет более 100.000
ориентировачно в дальнейшем ~ 400.000

 

[tony2001]

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

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

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

 

[diamond_krnl]

от версии к версии мускл становится всё сельнее.

тут делал апгрейд на сервер mysql: 3.7 -> 4.1, php: 4.3 - 5.0
скрипт экспорта с текстового файла заработал в ~6 раз быстрее,поясняю раньше 5000 записей / 30 полей, экспортилось за ~40 секунд, сейчас в средние 6-8 секунд.

что-то подшаманили с INSERT-ом.

 

[yugene]

Originally posted by tony2001
это что-то вроде:
"езжу на метро каждый день.
а получится ли проехать на метро вдвоем сразу?
потянет ли поезд?"

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

То-то поездам сейчас восьмой вагон пробуют цеплять

 

[tony2001]

yugene
обычно дешевле проапгрейдить рельсы, чем перестраивать станции.