Есть такая проблема. В нашей конторе есть электронный справочник, который продается на CD. сейчас он написан на Delphi и работает с Interbase. для того, чтобы пернести обновленную информацию в интернет (тот же справочник, но уже он-лайн) делается простое копирование файла базы данных. это встпуление...

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

поэтому решили переписать справочник (обе версии) под новую БД, но какую, не знаем. есть множество вариантов.

может быть подскажете что же выбрать?

Требования следующие:
1 Обеспечить многопользовательский доступ с большим количеством одновременных пользователей
2 Устойчивость к неполадкам оборудования, ПО сервера
3 Достаточная стойкость к несанкционированному доступу
4 Возможность хранения достаточно большого объема информации (предположительно до 10 Гб)
5 Отсутствие платы за лицензию или очень низкая цена
6 Возможность оперативного копирования базы справочника из локальной сети на веб-сервер без изменений
7 Должна одинаково эффективно работать:
-- на веб-сервере, под управлением специального программного обеспечения
-- на локальном компьютере пользователя (установкапрограммы справочника клиентам) без установки дополнительного ПО
-- на сервере в локальной сети для обновлении информации
8 Должна в достаточной степени поддерживаться языками программирования PHP и Delphi


буду благодарен любым конструктивным советам!

в общем, решили не переписывать CD-версию справочника - большой уж очень геморой

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

mysql-база лежит на серваке у хостера (сервак в принципе наш, на находится в дата-центре и доступ к нему через интернет), interbase-база находится в своей сети.

при подключении к базе мускуль что нужно прописывать? какой файл нужно указать в поле "Файл базы данных"? я поставил db.opt (порыскал в папках mysql), выдал ошибку: сначала что-то про невозможность найти libmySQL.DLL. нашел, засунул в папку с IBExpert, теперь выдает "access violation at address 00000000 read for address 00000000"

кто-то с этим сталкивался?

по поводу скорости работы базы: запросу простые и нанких заморок там не должно быть. просто сайт очень динамичный и одна страница (разные её части) генерируется из разных запросов. вот и все

Сервер:
FreeBSD
Apache
CPU 600Mhz, 192Mb memory

база работает с РНР. посмотреть можно здесь
http://www.bsfera.ru

по данным статистики сервера процессы fb_inet_server забирают почти 100% процессора и памяти (если процессов около 20 и более). от этого даже сервер падает.

по поводу запросов: главная страница строиться так
- три простых запроса, которые отображают статистику по новостям (например, select count(*) from source - количество источников)

- select first 10 news.ndate, news.nid, news.ncaption, news.ncontent, source.sid, source.sname, ntheme.ntid, ntheme.ntname from news, source, ntheme where news.NSID= source.sid and news.NNTID=ntheme.NTID order by ndate desc, NID desc - это вывод списка последних 10 новостей с указанием истояника и тематики

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

ВСЁ! никаких сложнейших запросов, лишь простое объединение таблиц

ну ещё на погода: подключается к RSS каналу и парсит его в ХHTML

хостинг кстати (виртуальный выделенный сервер) вот здесь http://firstvds.ru

есть, конечно, предположения о том, что проблемы могут быть на их стороне. писал с такими мыслями в сапорт, они кивают на жарптицу, мол это она у вас кушает много

ну, мы, конечно, собираемся приобретать свою машину

вот примерные парметры
1. CPU AMD Athlon 3800+
2. память 1Gb
...
что ещё можете добавить. уложиться приказано в тыщу рупий )))

StudSW
Может стоит подумать о переходе на с CS на SS.
Классик при большом числе коннектов ресурсы жрет больше (но равномеренее).


насколько я понимаю, что на двух-процессорном атлоне CS будет работать хуже, чем SS. а вот под любую ось будет нормально фурычить?

guest_20040621> вот примерные парметры

Серверы на Athlon не делают.

> уложиться приказано в тыщу рупий

Не получится.

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

miksoft DinamIKну, мы, конечно, собираемся приобретать свою машину
общий объем базы какой?
если не очень большой, то лучше поставить побольше оперативки, чтобы тяжелые SQL-запросы не насиловали дисковую подсистему.

Хотя, имхо, наиболее экономичное и, одновременно, перспективное решение - пересмотреть и оптимизировать используемые SQL запросы, т.к. тормознуть можно любую, самую крутую железку.

базы на самом деле две. 1- 50 Мб (растет не очень быстро, думаю предел - 100), а вот вторая - около 250 Мб и будет расти дальше, думаю до гигабайта