На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2004-3-9 на главную / новости от 2004-3-9
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 9 марта 2004 г.

Отчет: СУБД с открытым исходным кодом становятся мейнстримом

Следуя по стопам операционной системы Linux, СУБД с открытым исходным кодом начинают угрожать проприетарным альтернативам от Oracle, IBM и Microsoft.

«Сегодня СУБД open-source находятся на рыночной стадии экспериментирования, но к 2006 году начнется их массовое применение», говорится в отчете AMR Research. В декабре аналитическая фирма опросила 140 ИТ-менеджеров и теперь опубликовала результаты.

Главная опасность исходит от трех основных участников рынка СУБД open-source: MySQL, MaxDB и PostgreSQL, утверждает AMR.

Linux угрожает таким проприетарным операционным системам, как Microsoft Windows и Solaris от Sun Microsystems; следующие на очереди — базы данных, считает AMR. «Еще до наступления 2006 года поставщики традиционных СУБД почувствуют трудности с наращиванием качества и количества заказчиков (а также прибыли)», говорится в отчете.

Однако успех базам данных с открытым исходным кодом гарантирован не был. В 2001 году после неудачной попытки сделать бизнес на пакете PostgreSQL закрылась компания Great Bridge. А ведущий продавец Linux Red Hat, хотя и пытается вывести свой спектр ПО за пределы операционной системы, больше не включает в перечень приложений Red Hat свою Red Hat Database, вышедшую в 2001 году.

Однако исследование AMR обнаружило, что популярность баз данных с открытым исходным кодом растет. Одним важным фактором этого роста служит их низкая стоимость. «Из тех компаний, которые в ближайшие два года собираются оценить новую технологию базы данных, свыше 40% ставят на первое место стоимость», — пишет AMR. Традиционные производители СУБД берут за свое ПО до 40 тыс. долл. на сервер, тогда как максимальная цена СУБД с открытым исходным кодом составляет 1500 долл. на процессор для MaxDB.

Встать на ноги СУБД open-source поможет поддержка софтверных компаний. «Мы уверены, что многие независимые производители ПО в ближайшие два года объявят о поддержке той или иной СУБД с открытым исходным кодом, но те, кто будет действовать активно и встанет на этот путь в ближайший год, наверняка получат конкурентное преимущество», — утверждает AMR.

Один наглядный пример подала компания SAP, подписавшая в прошлом году соглашение с MySQL. Теперь MySQL разрабатывает СУБД с открытым исходным кодом от SAP под названием MaxDB и постепенно переносит ее функции в продукт MySQL, который продает уже много лет.

Еще один пример партнерства явила Sun Microsystems, которая встраивает в свой сервер каталога программное обеспечение Berkeley DB от Sleepycat. Это продукт open-source, который может продаваться и как проприетарный пакет; он не заменяет ПО СУБД (такое, как Microsoft SQL Server, IBM DB2 или MySQL), в котором используется стандартный язык формирования запросов к базе данных SQL.

Одним из факторов, сдерживающих принятие новых СУБД, является якобы отсутствие поддержки, однако, как утверждает AMR, «во многом эти опасения происходят от заблуждения о недоступности коммерческих контрактов по технической поддержке. У тех, кто имеет реальный опыт работы с базами данных open-source, они рассеиваются». Другим ограничивающим фактором служила поддержка сложных последовательностей команд, называемых хранимыми процедурами.

Пользователи СУБД с открытым исходным кодом удовлетворены этими продуктами больше, чем проприетарными альтернативами, в части цены, производительности, простоты администрирования, стабильности и существующих возможностей. Но когда речь заходит о «масштабируемости», то есть способности справляться с большими нагрузками, их удовлетворенность ослабевает, отмечает AMR. 

 Предыдущие публикации:
2004-01-13   MySQL совершенствует СУБД с открытым исходным кодом
2004-02-03   Oracle начинает поставки СУБД 10g
 В продолжение темы:
2004-04-21   Разменная монета open source
2004-05-27   В этом году Oracle полностью перейдет на Linux
2004-05-27   Microsoft укрепляет защиту базы данных
2004-05-31   НР расширяет поддержку open source
Обсуждение и комментарии
FrozenCat
9 Mar 2004 4:39 PM
Вот и СУБД... внимание получило
Затем MPR,CRM,ERP... :)
Closed-source private property...rip,
exclude private data :)
 

torvic
9 Mar 2004 5:52 PM
Вот и на наш консервный завод пришли современные технологии, теперь мы делаем банки данных
 

Александр - lawrosenergo.com
9 Mar 2004 6:06 PM
"Мейнстримом". "Вумный", как говорил про таких писателей В.И. Ленин. Просто занимают свою нишу некритичных к потере данных, сбоям и нагрузке приложений. Если заваливается "взрослая" система, которая заваливаться не должна, то радости от открытого кода совсем нет никакой.
 

Mikhail Elashkin - imhoelashkin.com
9 Mar 2004 6:59 PM
2 Александр
Ну, большие системы тоже были маленькие. Когда-то корреспондент спросил Ларри Элиссона: "Первые версии Oracle были крайне неустойчивыми, были ли у вас случаи когда клиенты требовали деньги назад?"
"Деньги? Не помню такого" - ответил Ларри - "А вот свои данные назад просили!" :) Реальный факт.
Безусловно, пока они не доросли, но...
Что до слов FrozenCat об Open source ERP, то на свете много людей, которые знают как строить ОС, но очень и очень мало тех кто имеет подобные знания и опыт в ERP.

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

nickoil
9 Mar 2004 8:09 PM
почему-то в таких статьях постоянно аккуратно стороной обходится open sourse СУБД Firebird. а она, между прочим, весьма популярна. вместо этого вытащили на свет божий какого-то чудного зверя в виде maxdb.
вселенский сговор, что ли? ;)
 

Tre
9 Mar 2004 9:01 PM
Всем привет. По роду деятельности мне пришлось бывать в этом году в Китае. И вот сегодня я сделал для себя открытие. Open-sourse мне напоминает китайскую продукцию: на вид она такая же функциональная (и станки и сотовые телефоны) и цена великолепная, но есть свои НО. Оно не такое же точное, как немецкое оборудование, собирается в кустарных мастерских (я там побывал множество раз), не достаточно удобное в работе, и инструкция на китайском языке:))))
 

Tre
9 Mar 2004 9:03 PM
Да, и еще, когда нужна НАДЕЖНОСТЬ и ТОЧНОСТЬ, приходится брать немецкое оборудование:))
 

Не Лох
9 Mar 2004 9:05 PM
Точно, Interbase (Firebird) не упомянули.
Какая то MaxDB вылезла. Я помню совсем недавно она называлась SAPDB.
Но вообще все правильно. MySQL используется такими гигантами как Yahoo и Ebay. Так что испытание прошла.
 

MX
9 Mar 2004 10:45 PM
>Да, и еще, когда нужна НАДЕЖНОСТЬ и ТОЧНОСТЬ, приходится брать немецкое оборудование:))

Сделанное на китайских заводах:)
 

Не Лох
9 Mar 2004 11:15 PM
2 MX
:))) Точно.
Все эти Dell, HP, Compaq на самом деле Acer, BenQ, LiteOn.
Ребрендинг называется.
 

Yuri Abele
10 Mar 2004 12:15 AM
Ничего если я вас отвлеку и вернусб к самой статье? :-)

Про цену - согласен,
про скорость _на простых операциях_ - согласен
но про
- простоту администрирования,
- стабильность
- существующие возможности (особенно они)
это, хм несколько не так. Это какими таким дополнительными возможностями обладает, к примеру, MySQL по сравнению с тройкой коммерческих лидеров? Вот что в нем нет - список длинный. Но уже достаточно отсутсвия полноценной поддержки вложенных запросов, связанных подзапросов и JOIN-в.
XML он наверное тоже встроенными средствами генерить умеет? А произвольной (не привязанной к схеме соединений запроса) структуры?
Чего сочинять-то?
 

FrozenCat
10 Mar 2004 1:59 AM
2>10 марта, 2004, 0:15 - Yuri Abele
Зачем же MySQL ?
Есть PostgreSQL, Firebird - они потихоньку подбираются к 3 ком.лидеров.
 

FrozenCat
10 Mar 2004 2:05 AM
2>9 марта, 2004, 18:59 - Mikhail Elashkin
В целом согласен, но проблема не такая и большая как кажется...
 

Ёжи
10 Mar 2004 10:14 AM
to Yuri Abele

> существующие возможности

Речь идет об PostgreSQL, который действительно имеет некоторые инновационные преимущества, тот же cell lock, реальный snapshot.
 

Павел - m_pashkamail.ru
10 Mar 2004 10:14 AM
А в общем то все закономерно. У монстров ПО есть все - деньги, ресурсы, клиентская база. Поэтому их продукты закономерно лучше. Но они стоят на месте - буксуют. Поэтому даже опен-сорц - поделки энтузиастов начинают их догонять. И это закономерно. И так будет. Либо проприетарщики делают что-то прогрессивное, либо умирают. Ибо стоимость продукта в любом случае должна определяться его себестоимостью (по законам рынка). Если себестоимость много ниже и выгода очень большая, то найдется другой производитель, который сделает то же, но с меньшей выгодой для себя и с большей привлекательностью для потребителя. И проприетарный софт никогда не умрет, покуда надо будет что-то делать. А начнет плесневеть и застаиваться - опен сорц его подтолкнет... Если только СКО новый закон не пробьет о том, что делать бесплатное ПО незаконно.
 

Читатель
10 Mar 2004 10:28 AM
О да, Firebird - это панацея :) Я тут недавно сравнивал Interbase,Firebird и MSSQL - на одном и том же железе мелкомягкий сервер рвет своих бесплатных конкурентов как тузик грелку. Причем база небольшая была - в одной таблице 30 тыс., в другой 2.5 млн. записей, так примитивный запрос со сцепкой, группировкой и сортировкой MSSQL выполняет в 3 (три) раза быстрее! Я уж не говорю про функциональность - у MSSQL в триггерах можно создавать временные таблицы и с ними работать, также в MS можно выполнить запрос к таблицам, размещенным в разных базах данных на разных серверах, как будто они находятся в одной базе данных.
 

Peter - PeterSuperyandex.ru
10 Mar 2004 10:33 AM
Упорное и последовательное замалчивание о таком продукте, как Firebird, это конечно штука проплаченная. Как тут не вспомнить известное словоблудие о свободной прессе. Свободной действительно от всех,кроме своего хозяина...!!!
Про MySQl, у которого нет даже хранимых процедур, говорить даже не хочется, но вот Interbase является встроенной СУБД современного танка Абрамс! Так что,эти америкосы из военного ведомства спятили? Все? Их же там очень и очень много,как грязи! Кто-нибудь ответит?
 

Ёжи
10 Mar 2004 10:39 AM
> Я тут недавно сравнивал ....

Да вы батенька эксперт !!!
 

Читатель
10 Mar 2004 10:40 AM
2 Ёжи: кстати, как там в postgresql обстоят дела с транзакциями? Допустим, я нечаянно сделал delete from price - поможет ли мне rollback?
 

Ёжи
10 Mar 2004 10:47 AM
И что не мог???

Чем же вы пользовались?

 

Ёжи
10 Mar 2004 10:48 AM
И что не помог???
 

Читатель
10 Mar 2004 11:43 AM
Я postgresql не пользовался, вот и спрашиваю :) В СУБД, поддерживающих транзакции - помогает
 

Ron
10 Mar 2004 11:56 AM
2 Читатель.
> Допустим, я нечаянно сделал delete from price - поможет ли мне rollback?

Вы сами-то поняли, что сказали?
 

СтранниК
10 Mar 2004 12:19 PM
Я тоже вот стараюсь отслеживать развитие Open-Source СУБД.
И на мой взгляд самым реальным претендентом, на замену комерческим аналогам я вижу только MAXDB или как ее раньше называли SAPDB.
Да, там еще конечно требуются доработки, но.
Если смотреть на результаты комерческого теста SAP-SD, то результаты постоянно улучшаются и я бы сказал радуют глаз.

Из того чего нет в MAX-DB, я бы назвал:
- отсутствие партицирования
- отсутствие средств для постороения DATAWAREHOUSE
- отсутствие OLAP cервиса.

Конечно это наверно пока не так страшно, особенно если учесть цену продукта.
Ну и чего лично мен в MAX-DB не хватает, после чего я бы серьезно начал тестировать продукт:
- проблемы с локализацией.
- в свое время команда обещала сделать мульти-версионность, но что-то забыли они про это.
 

Ёжи
10 Mar 2004 1:24 PM
> Ну и чего лично мен в MAX-DB не хватает, после чего я бы серьезно начал тестировать продукт:
- проблемы с локализацией.
- в свое время команда обещала сделать мульти-версионность, но что-то забыли они про это.

Ну тогда вам к postgresql

А если учесть, что он сейчас успешно заменяет "коммерческие аналоги" в high-end (например, библиотека конгресса), то ...

Вот только сложен в освоении, требуется изучать теорию. Хотя последние версии приблизились к простому разработчику.
 

СтранниК
10 Mar 2004 1:51 PM
2Ёжи
А там уже есть сделали онлайн-бэкап и нормальное логирование?
Функционала там конечно море и довольно интерестного, но вот производительность этого функционала....

 

Mikhail Elashkin - imhoelashkin.com
10 Mar 2004 3:39 PM
2 Павел
>Поэтому их продукты закономерно лучше. Но они стоят на месте - буксуют.

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

Mikhail Elashkin - imhoelashkin.com
10 Mar 2004 3:42 PM
2 СтранниК

>Из того чего нет в MAX-DB, я бы назвал:
- отсутствие партицирования
- отсутствие средств для постороения DATAWAREHOUSE
- отсутствие OLAP cервиса.

Ну, это к вопросу о том, что опен сорс не сравним по мощности с коммерческим. Все эти штучки сделаны давно в коммерческих проектах, но для опенов это еще время. За это время коммерческие еще оторвутся... итп.
А вообще, рано или поздно интерес пропадет и к СУБД. Станет стандартным продуктом, как сейчас файловая система.... :)
 

СтранниК
10 Mar 2004 4:14 PM
2Mikhail Elashkin

Я считаю,что сейчас СУБД очень сильно перегружены бог-знает чем, и часто не очень нужными фичами.

На самом деле не все так плохо.
Вы ведь Михаил прекрасно знаете, что коммерческие компании тоже много чего не договаривают.
Ну пример Oracle RAC( раньше назывался как Oracle Parallel Server )
Cколько прошло лет прежде чем у Oracle появились приличные результаты ?
Я слышал про OPS еще в версии 7 ( это примерно 90-годы ).
То есть чтобы его довести до ума Oracle понадобилось 14 лет?

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

Насчет OLAP, так Oracle тоже не сразу сделал его сделал, не за один год.

Насчет сравнения файловых систем и БД.
Скажу, что хорошие файловые системы все так же в цене.
Пример VeritasFS сколько стоит ? Неприлично дорого.
Так же будет и с СУБД.
 

СтранниК
10 Mar 2004 4:19 PM
Но если абстрагироваться и подойти формально, то ничто не мешает использовать SAP-DB(MAX-DB) например для эксплуатации SAP R/3.
И уж согласитесь Михаил, тут есть на чем сэкономить.
 

Anatem
10 Mar 2004 6:23 PM
2Ёжи: А вот у меня вопрос, какая из опен-сорс СУБД(если их уже так можно назвать) умеет делать банальнейшую, но жизненно необходиму вещь: Transaction Log Backup? :)
Хочу с одной БД Transaction Log снимать, а на другой тут же поднимать, к примеру с шагом в минуту, так надо. Вторая БД будет Standby, что б если, что по быстрому перевести в Online.
 

СтранниК
10 Mar 2004 6:55 PM
2Anatem
Понимаю вас.
Вот поэтому и считаю MAXDB почти реальной альтернативой.
Она как раз умеет подерживать standby-db
 

Vanoha
10 Mar 2004 8:07 PM
2 Anatem 10 марта, 2004, 18:23

Такую задачу можно решить на MySQL - см. документацию.

Можно через логи, а можно и через online реплику.
Более того, при использовании реплики можно читать с обоих (всех) узлов.

 

FrozenCat
10 Mar 2004 10:59 PM
2>All
Повторю, кто оспориит???
Mножество ком.разработок есть подмножество социума.
В то время как социум это и есть множество на данный момент.
 

Громокряк
11 Mar 2004 8:29 AM
"Птичку жалко". за что ее так вниманием обошли? и это при том, что firebird:
-прост в конфигурировании и обслуживании. очень прост.
-обладает великолепной функциональностью.
-высокая устойчивость к сбоям.
-версионник, в отличие от MS. тут "Читатель" ниже писал, что MS обошел по скорости firebird. это закономерно, т.к. MS- блокировочник, он не тратит доп. время на учет версий. MS и Oracle порвет по скорости (см. результаты тестов TPC)- по той же причине (архитектурные особенности).
-многие программисты отмечают изящество и логичность psql firebird'a. на нем легче программировать.
 

СтранниК
11 Mar 2004 11:00 AM
2Громокряк
версионник, в отличие от MS. тут "Читатель" ниже писал, что MS обошел по скорости firebird. это закономерно, т.к. MS- блокировочник, он не тратит доп. время на учет версий. MS и Oracle порвет по скорости (см. результаты тестов TPC)- по той же причине (архитектурные особенности).
===
Это ерунда, насчет того, что блокировочник быстрее.
Это из области фантастики.

Вы себе вообще представляете работу версионника ?
На TPC попрошу не ссылаться, потому как там есть много если.
 

Поручик
11 Mar 2004 12:17 PM
firebird не требует дорогого админа баз данных. С обслуживанием систем на его базе справляется вчерашний студент. Зачастую заказчик работает и не знает, что у них на компьютере исользуется СУБД, которую нужно администрировать - действий по обслуживанию нужен минимум.
Тот же MSSQL требует для нормальной работы спеца, прошедшего дорогие курсы, знающего очень много об этой большой системе и претендующего на соответствующий оклад.
 

FWP
11 Mar 2004 12:41 PM
"А вот у меня вопрос, какая из опен-сорс СУБД(если их уже так можно назвать) умеет делать банальнейшую, но жизненно необходиму вещь: Transaction Log Backup? :)"
FireBird к примеру не умеет и никогда не будет уметь. Т.к. "Transaction Log" отсутствует по определению.

"Хочу с одной БД Transaction Log снимать, а на другой тут же поднимать, к примеру с шагом в минуту, так надо. Вторая БД будет Standby, что б если, что по быстрому перевести в Online."
Все клоны IB начиная с версии 1812 года умеют это делать. И без всяких проблем!
 

FWP
11 Mar 2004 12:53 PM
"О да, Firebird - это панацея :) Я тут недавно сравнивал Interbase,Firebird и MSSQL - на одном и том же железе мелкомягкий сервер рвет своих бесплатных конкурентов как тузик грелку. Причем база небольшая была - в одной таблице 30 тыс., в другой 2.5 млн. записей, так примитивный запрос со сцепкой, группировкой и сортировкой MSSQL выполняет в 3 (три) раза быстрее!"
А попробуй такой простой тест как вставка 100000 записей в ОДНУ таблицу. FB рвет мелко мягких точно так же:-)

"Я уж не говорю про функциональность - у MSSQL в триггерах можно создавать временные таблицы и с ними работать, также в MS можно выполнить запрос к таблицам, размещенным в разных базах данных на разных серверах, как будто они находятся в одной базе данных."
Хочешь я тебе раскажу чего нет в MSSQL или появилось только в 2000 версии, в то время как мы этим уже давно пользуемся?
 

done
11 Mar 2004 9:17 PM
2FWP
>А попробуй такой простой тест как вставка 100000 записей в ОДНУ таблицу.
>FB рвет мелко мягких точно так же:-)
ну дк у FB нет транзакшнлога
а случись неприятность (СУБД, ОС или железка упадет прямо на базу и с треском)
что делать будешь??
 

Громокряк
12 Mar 2004 8:41 AM
Странник, я прекрасно разбираюсь в архитектуре и блокировочников и версионников, потому и говорю что блокировочник пожизненно будет быстрее версионника. TPC я привел в качестве яркого и официального примера, иллюстрирующего мои слова. а так, я являюсь активным участником кофн. по БД. периодически народ там затевает тесты. так вот, на разных тестах результат всегда один- блокировочник быстрее. и говорить не надо, что мол условия тестирования были неверными- тесты то проводили разные люди, в разное время, на разном оборудовании, настройках, а результат получали тот же. зато версионники существенно надежней блокировочников, быстрей восстанавливаются после сбоя.
в общем, у каждого своя область применения.
 

Читатель
12 Mar 2004 9:45 AM
2 FWP : "А попробуй такой простой тест как вставка 100000 записей в ОДНУ таблицу. FB рвет мелко мягких точно так же:-)"
Пробовал (правда, с Interbase) - если каждый insert проходит как одна транзакция, то MS быстрее где-то раз в 20..30 :)

"Хочешь я тебе раскажу чего нет в MSSQL или появилось только в 2000 версии, в то время как мы этим уже давно пользуемся?" Конечно хочу. Интересно, что могло быть крутого в FB до 2000 года?
 

СтранниК
12 Mar 2004 10:26 AM
2Громокряк
Вы давно на www.tpc.org ходили?
 

СтранниК
12 Mar 2004 10:31 AM
Для тех кому интерестно подтверждение того , что если у кого что и получится так это у SAPDB(MAXDB)
Fujitsu Siemens Computers PRIMERGY Model TX600/RX600, 4-way SMP, Intel Xeon MP 2.8 GHz, 20 KB L1 cache, 512 KB L2 cache, 2 MB L3 cache
SuSE Linux Enterprise Server 8 SAP DB 7.3.0

SAPS=2700 USERS=536

Аналогично для коммерческой СУБД
Fujitsu Siemens Computers PRIMERGY Model TX600/RX600, 4-way SMP, Intel Xeon MP 2.8 GHz, 20 KB L1 cache, 512 KB L2 cache, 2 MB L3
Windows Server 2003 Enterprise Edition SQL Server 2000
SAPS=2730 USERS=542

Я бы сказал, что "спортсмены шли очко в очко"
 

FWP
12 Mar 2004 11:41 AM
"а случись неприятность (СУБД, ОС или железка упадет прямо на базу и с треском) что делать будешь??"
А ты?
 

FWP
12 Mar 2004 12:22 PM
"Пробовал (правда, с Interbase) - если каждый insert проходит как одна транзакция, то MS быстрее где-то раз в 20..30 :)"
Ну да, и IB4 и каждый insert проходит как одна транзакция, и У MSSQL BULK INSERT!
А я вот тоже пробовал. FB 1.5 и MSSQL2000. Так обратная ситуация.

"Интересно, что могло быть крутого в FB до 2000 года?"
Подписка на события к примеру.
 

done
12 Mar 2004 2:28 PM
2FWP
я просто не буду использовать игрушечную СУБД типа FB,
а с нормальной СУБД я восстановлюсь из архивов и накачу логи
;-)
 

Поручик
12 Mar 2004 3:37 PM
2 done

А если задача копеечная? Неужто лицензию на нормальную СУБД покупать?
 

FWP
12 Mar 2004 3:53 PM
я просто не буду использовать игрушечную СУБД типа FB, а с нормальной СУБД я восстановлюсь из архивов и накачу логи
;-)
Особенно хорошо это получится, если логи тоже навернулись.
 

добрый
12 Mar 2004 4:39 PM
2Поручик: опять же что считать копеечной. по Москве много где R-Keeper работает. ПОСы. База - IB. И обороты получаются некопеечные.
 

Прохожий
12 Mar 2004 6:13 PM
2 Громокряк

А расскажите, пожалуйста, что вас сподвигло на ту мысль, что блокировочник будет ВСЕГДА быстрей версионника? И сходите еще раз на tpc.org.
 

Прохожий
12 Mar 2004 6:17 PM
2 FWP

А если логи всё-таки не навернулись. Если логи, к примеру, реплицируются еще в несколько мест? По крайней мере хоть возможность такая есть для коммерческих СУБД. А как в случае с FB?

И еще. Что важнее, по-вашему, стоимость СУБД или данных в крупных компаниях?
И далее. И много ли на вашей практике встречается таких вот простых вставок в одну таблицу? То есть каково процентное соотношение простых вставок в одну таблицу и сложных болеее-менее запросов в мало-мальски сложном проекте ?
 

pal
12 Mar 2004 7:01 PM
да уж, opensource dbms никогда не догонят коммерческих. просто потому, что все opensource, представленные в статье являются коммерческими
 

Поручик
13 Mar 2004 12:56 PM
2 pal

Firebird не является, но по исполнению он на уровне коммерческих. (Правда и в статье о нем ни слова не сказано)
 

FWP
15 Mar 2004 11:51 AM
"А если логи всё-таки не навернулись. Если логи, к примеру, реплицируются еще в несколько мест? По крайней мере хоть возможность такая есть для коммерческих СУБД. А как в случае с FB?"
Аналогично. Если ОС осталась живая, и теневая БД находилась на другом носителе, то и накатывать ничего не надо. Переход на тень произойдет автоматически.
 

FWP
15 Mar 2004 11:56 AM
" И много ли на вашей практике встречается таких вот простых вставок в одну таблицу? То есть каково процентное соотношение простых вставок в одну таблицу и сложных болеее-менее запросов в мало-мальски сложном проекте ?"
Да я это привел как аргумент, что при проектировании приложения нужно учитывать особенности конкретной СУБД. И строить соответствующие запросы. А задачи с массовой заливкой данных вовсе не редкость.
 

pal
15 Mar 2004 3:00 PM
еще бы. 20 лет был коммерческим, а как исходники открыли - сразу должен стать хуже ? ;)
 

Black Bat
15 Mar 2004 5:06 PM
а вот у нас 2000 таблиц в системе. представляю, как бы это всё работало на бесплатной субд :)
 

Поручик
15 Mar 2004 6:21 PM
2 Black Bat

Нормально работало бы. У знакомых складской учет в супермаркете на Firebird работает в реальном режиме времени. Хорошо справляются.
 

Black Bat
15 Mar 2004 7:21 PM
to Поручик:

ну да, если такая сложная система как _складской учет в супермаркете_ работает... :)))
 

Прохожий
15 Mar 2004 7:25 PM
2 Поручик

А размер базы данных какой? Сколько таблиц в системе? Сколько пользователей в системе?
 

torvic
16 Mar 2004 12:35 AM
MySQL database to get high-end feature
http://zdnet.com.com/2100-1104_2-5173101.html
Анонсируются две фишки:
- MySQL Cluster, куплено у Ericsson. Обещают переключение на другую ноду в течении 1 сек.
- хранимые процедуры из MaxDB, которую обещают поддерживать еще 10-15 лет.
 

FWP
16 Mar 2004 10:34 AM
Видел одну систему. На FoxBase писаную. Тож было 2000 таблиц. В 1992 году. Ну и что?
 

torvic
16 Mar 2004 12:20 PM
Это было не pro и не contra, а just for info.
 

Поручик
16 Mar 2004 3:38 PM
2 Прохожий

Врать не буду, т.к. не знаю. Явно не 2К таблиц.

Думаю, со временем коммерческие СУБД будут вытеснены в сектор больших и очень больших решений, т.е. туда, где за них есть смысл платить. А малые и средние задачи (которых большинство) будут решаться с использованием бесплатных СУБД, т.к. они прекрасно с ними справляются.
 

Прохожий
17 Mar 2004 11:09 AM
2 Поручик

Думаю, что размер СУБД - это не главный критерий оценки полезности СУБД.
Где-то видел опрос корпоративных пользователей. Так там первые места занимали надежность и функциональность.
 

Поручик
18 Mar 2004 12:28 PM
2 Прохожий

Согласен с вами. Но я говорю не о размере СУБД, а о масштабах задач, с помощью нее решаемых. Для задач, не являющихся большими и очень большими, существующие бесплатные СУБД обеспечивают нужную надежность и достаточную функциональность.
 

done
19 Mar 2004 10:10 AM
2ggv имей совесть
а если тебе начнут на французком или немецком отвечать??
 

Поручик
19 Mar 2004 1:02 PM
Шановний GVV, якщо в адміна або проектувальника системи руки ростуть не з того місця, або не потурбуватися про електроживлення та ще багато речей, то можна завалити будь-яку базу даних на будь-якому сервері.
 

ggv
19 Mar 2004 4:25 PM
Поручик - I'm glad to read "ridnu movu" (sorry, 'done', last time.... "molchu")
 

Хрю
19 Mar 2004 5:53 PM
2ggv:
"I'm far away from a firebird, do not work with it..."

Вот интервью человека кторый в курсе - ведущего разработчика firebird:
http://www.interbase-world.com/ru/community/interviews/2122 .php

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

Поручик
19 Mar 2004 6:54 PM
2 Хрю

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

Хрю
19 Mar 2004 7:14 PM
2Поручик:
А вот у нас тут парни будут похоже вынуждены заказчиком лепить на этой опынсорцной помоине. :(
 

anest - anest5mail.ru
20 Mar 2004 2:27 PM
главная проблема бесплатных субд - это поддержка стандартов. До тех пор пока эта проблема не будет решена не 100% (или хотя бы на 95% :), говорить о них как о серьезных альтернативах - смешно.

Я не знаком со всем списком, но особенности SQL в столь популярной MySQL впечатляют!!!

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

fi
20 Mar 2004 7:51 PM
to anest, откуда такая увереность? Не смешите людей насчет SQL стандартов, их реально просто нет, то что называется 92 не более чем база.
 

torvic
20 Mar 2004 10:01 PM
2 fi
MySQL TO-DO: In the long run we plan to be fully ANSI 92 / ANSI 99 compliant.
 

Engineer - motuszebratelecom.ru
28 May 2004 12:33 PM
Читателю.
Interbase лучше чем MSSQL. При программировании на MSSQL лучше не использовать триггер и курсор. Триггер в MSSQL очень плохой: существует только триггер after (в том числе и instead) и срабатывает после выполнения всех манипуляций запроса с таблицей. Не удивительно, что сервер иногда быстро работает. Платой за это является сложный код и все преимущество быстроты съедает время разработки, отладки, тестирования и сопровождения, причем этот сложный код работает медленно. Тут уместно заметить, что на последовательных (плоских) файлах можно достичь гораздо большей производительности, чем может дать СУБД. Однако на то и делали СУБД, чтобы она позволяла не реализовывать заново давно написанные и часто используемые функции. Про курсор забыть сложно: отказаться полностью нельзя, хотя работает очень медленно.
Утилита командной строки isql работает так медленно (isqlw немного быстрее), что мне пришлось написать аналогичную программу на jscript в 100 строк, которая работает быстрее более чем в 10 раз. Если кого-то заинтересует этот скрипт, напишите motus@zebratelecom.ru, я пришлю.
Это только небольшая часть неприятностей. Большое неудобство также создают так называемые “особенности” MSSQL, описание которых занимает большую часть руководства bookOnLine. По моему мнению MSSQ далека от СУБД ANSI92.
 

 

← февраль 2004 4  5  7  8  9  10  11  12  14 апрель 2004 →
Реклама!
 

 

Место для Вашей рекламы!