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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Igor Vaskov
To : VadimT
Subj : Посоветуйте СУБД
> > > Возможно, я этим займусь, но только после того, как сделаю "вычислительную" часть проекта.
> >
> > Буду благодарен. У Шмедли можно спросить, что он там на портировал в части MySQL стандарта.
>
> Это ещё неизвестно, когда будет, если вообще будет. Но идея использовать портированный софт там, где нужны максимум совместимости, надёжности и производительности, меня изначально не прельщала. Жаль, что нет сейчас под ОС/2 ни одной живой нативной СУБД. Фирма Sundial, давшая осевикам Mesa 2, разработала DBExpert. Но я так понял из описания, что это не СУБД, а нечто вроде средства разработки интерфейсов к базам данных Oracle и DB2. Ещё хотел спросить: Adabas из OpenOffice.org и Lotus 1-2-3 из SmartSuite - это несерьёзно?

DBExpert - это средство выполнения SQL запросов на существующих серверах. А с Adabas я не встречался и ничего сказать не могу.

>
> > Вот кстати на ru2 MySQL после включения кэша стал виснуть раз в три дня. Заканчиваются семафоры. Открывает слишком много и ставит колом всю систему. А до этого без кэша работал стабильно. И не могу понять что случилось. На другом хостинге та же связка с кэшированием не виснет. Может нагрузка, может еще что...
>
> Если MySQL хоть где-то работает нормально с кэшем, значит, он на это в принципе способен. Следовательно, если он где-то работает с кэшем ненормально, то дело не в нём. Может, настроен не так, может, запросы кривые, может, в самой БД накопились ошибки. Кстати, я на просторах сети встречал такой совет: если возможностей MySQL 4.1 хватает, лучше использовать именно его. Он умеет мало, зато хорошо.

Совет здравый. Но к моему большому сожалению развитие программных продуктов сейчас происходит в корне не правильно.
Настоящая тенденция - максимальное усложнение модели в ущерб тестированию и устранению ошибок. Т.е. добавляются все новые и новые функции, расширяются возможности. Как следствие падает скорость исполнения программ и добавляются сложно выявляемые ошибки вследствие большого количества взаимоствязей. Скорость выполнения компенсируют увеличением мощности железа, а ошибки - макркетингом (Ну и что что глючит? Зато умеет чесать гланды через задницу.)
Когда-то этот путь прошли процессоры. Сначало тоже гнались за увеличением количества комманд и функционала. А потом появилась архитектура RISC. И сразу стало понятно, что наконец-то можно сделать чип, который может не глюча и быстро выполняь 10-20 комманд. А остальное можно реализовать на этом наборе комманд.

>
> > > Кстати, у меня SSD.
> >
> > А SSD пилить вообще не рекомендуется.
>
> Что значит "пилить"? Создавать большую нагрузку?

Не совсем. Для SSD критичны операции записи на диск. Запись разрушает носитель информации. Чтение не разрушает.

> Так это я и сам знаю. Это тоже навело меня на мысль обустроить свою собственную СУБД. Если Вы читали принцип её работы, то наверняка обратили внимание, что она будет создавать минимально возможную нагрузку на диск.

Это понятно и здорово. Но проблемы, как я говорил ранее, в отладке. Но при небольшом количестве функций и проблем меньше.

>
> > DB2 хорошая штука. И с Осью работает наиболее оптимально. Но MySQL все-таки халява, а DB2- лицензия.
>
> Это не проблема. Главное, чтобы моя прога работала с БД быстро, надёжно, эффективно, с минимальной нагрузкой на оборудование. При этом надо учитывать, что под надёжностью понимается в первую очередь отсутствие ошибок в данных. Потеря данных не будет трагедией. Поясню. Допустим, мы начали работу с заведомо безошибочной БД. Нагружали её данными целый час. Вдруг что-то произошло, мы потеряли все новые данные, БД вернулась к исходному состоянию. Это неприятно, но не смертельно. А вот если в БД сохранятся все данные, за исключением одной ячейки таблицы, то произойдёт катастрофа. Рассогласованные дынные станут не только бесполезны, но вредны и опасны.

Как обычно бывает, задача не простая и требует проведения НИР, а не мозгового штурма ;) Кстати, для OS/2 существовали какие-то версии B-Tree базы данных. Есть ли оно в исходниках и где - не знаю. Но если есть, то может имеет смысл посмотреть.


Sat 19 Mar 2011 16:56 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1.11) Gecko/20



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.