| QUOTE (jalt @ 27.02.2006 - время: 08:56) |
| Вроде есть... а как это относится к теме вопроса? |
Да ни как, просто ищу аналог MS SQL, но все аналоги спотыкаются на том, что у них есть поле data и есть time (иногда), но нету именно data-time.
А по теме - переход на линух тебе даст повышение надёжности и всё.... это если у тебя однопроцессорная тачка.
А если у тебя сервачёк двух и более процессорный (пусть даже логически) то это тебе должно дать еще и нехилую прибавку в производительности, потому как поддержка многопроцессорности у линух на уровне операционной системы, а не на уровне приложений (как у винды).
| QUOTE (AngeLR_W @ 05.03.2006 - время: 19:31) | ||
Да ни как, просто ищу аналог MS SQL, но все аналоги спотыкаются на том, что у них есть поле data и есть time (иногда), но нету именно data-time. |
Oracle - есть и то и другое ...
MySql - тоже есть ... и то и другое ... но есть проблема с локалями или быть может я до конца в него не въехал ... использую в осносном MS SQL 2000/2005
| QUOTE (AngeLR_W @ 05.03.2006 - время: 19:31) | ||
Да ни как, просто ищу аналог MS SQL, но все аналоги спотыкаются на том, что у них есть поле data и есть time (иногда), но нету именно data-time. А по теме - переход на линух тебе даст повышение надёжности и всё.... это если у тебя однопроцессорная тачка. А если у тебя сервачёк двух и более процессорный (пусть даже логически) то это тебе должно дать еще и нехилую прибавку в производительности, потому как поддержка многопроцессорности у линух на уровне операционной системы, а не на уровне приложений (как у винды). |
ну сейчас на двухпроцессорном ксеоне под виндой работает. но почему-то сервис периодически останавливается, и прочие глюки возникают. а на линухе у меня Р4-3.0, собст-но надежность мне и нужна...
Pervasive - как сказал бы какой нибудь падонок - это полный "ужос, нах!".
Единственное обоснованное его использование - в силу исторических причин.
Его, ИМХО, нельзя использовать вообще, а уж тем более в качестве альтернативы MsSQL. C Date и с Time все проблемы решаются на "раз-два" везде. К слову о птичках - язык SQL для Pervasive вообще не является родным. Если с этим возникают проблемы - спросите/почитайте в соответствующем месте.
Касательно переноса на Linux. Большого прироста производительности НЕ будет. Будет много гововной боли. Все тормоза - из-за нелепой архитектуры Pervasive, которая уже устарела морально лет на 20. Там каждый клиент работает с базой как с набором файлов, причем pervasive ему в этом как-то способствует. Ну т.е. представьте что каждый из 30 клиентов по сети гоняет большие куски нескольких больших файлов, при этом каждому клиенту с каждым файлом как-то "помогает" работать демон работающий на серваке... Ужас!
ЧТо касается решений:
1) плюнуть и забыть. (экономия нервов.)
2) попробовать аккратно оптимизировать настройки - прежде всего настройки кэша на сервере. (см. по этому поводу http://support.softlab.ru/forum/ZoneForum/...ult.asp?Forum=6
ftp://ftp.softlab.ru/pervasive/document/PSQL_Conf.pdf ) При этом самые удачные варианты - когда кэш оч. большой и редко "флэшится" на диск. Но в этом случае обязательно использование контролируемого бесперебойника.
3) проапгрейдить железо (причем нужно апгрейдить все - винт, проц, память и сетевуху). На 30 клиентов уже желательно использовать RAID5, лучше 2 проца, как минимум гиг оперативки и желательно серверную сетевуху. Вот так, блин.
переход на linux (ИМХО) бесполезен.