RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > Возможно, я этим займусь, но только после того, как сделаю "вычислительную" часть проекта.
> > 
> > Буду благодарен. У Шмедли можно спросить, что он там на портировал в части MySQL стандарта. 
> 
> Это ещё неизвестно, когда будет, если вообще будет. Но идея использовать портированный софт там, где нужны максимум совместимости, надёжности и производительности, меня изначально не прельщала. Жаль, что нет сейчас под ОС/2 ни одной живой нативной СУБД. Фирма Sundial, давшая осевикам Mesa 2, разработала DBExpert. Но я так понял из описания, что это не СУБД, а нечто вроде средства разработки интерфейсов к базам данных Oracle и DB2. Ещё хотел спросить: Adabas из OpenOffice.org и Lotus 1-2-3 из SmartSuite - это несерьёзно?
> 
> > Вот кстати на ru2 MySQL после включения кэша стал виснуть раз в три дня. Заканчиваются семафоры. Открывает слишком много и ставит колом всю систему. А до этого без кэша работал стабильно. И не могу понять что случилось. На другом хостинге та же связка с кэшированием не виснет. Может нагрузка, может еще что...
> 
> Если MySQL хоть где-то работает нормально с кэшем, значит, он на это в принципе способен. Следовательно, если он где-то работает с кэшем ненормально, то дело не в нём. Может, настроен не так, может, запросы кривые, может, в самой БД накопились ошибки. Кстати, я на просторах сети встречал такой совет: если возможностей MySQL 4.1 хватает, лучше использовать именно его. Он умеет мало, зато хорошо.
> 
> > > Кстати, у меня SSD.
> > 
> > А SSD пилить вообще не рекомендуется.
> 
> Что значит "пилить"? Создавать большую нагрузку? Так это я и сам знаю. Это тоже навело меня на мысль обустроить свою собственную СУБД. Если Вы читали принцип её работы, то наверняка обратили внимание, что она будет создавать минимально возможную нагрузку на диск.
> 
> > DB2 хорошая штука. И с Осью работает наиболее оптимально. Но MySQL все-таки халява, а DB2- лицензия.
> 
> Это не проблема. Главное, чтобы моя прога работала с БД быстро, надёжно, эффективно, с минимальной нагрузкой на оборудование. При этом надо учитывать, что под надёжностью понимается в первую очередь отсутствие ошибок в данных. Потеря данных не будет трагедией. Поясню. Допустим, мы начали работу с заведомо безошибочной БД. Нагружали её данными целый час. Вдруг что-то произошло, мы потеряли все новые данные, БД вернулась к исходному состоянию. Это неприятно, но не смертельно. А вот если в БД сохранятся все данные, за исключением одной ячейки таблицы, то произойдёт катастрофа. Рассогласованные дынные станут не только бесполезны, но вредны и опасны.

_, __, _, __, /_\ \|_) /_\ \|_) \| \| \| \| \| \| \ ~ ~ ~ ~ ~ ~ ~