Проприетарные СУБД обречены?

ораклокапец?

Fireird на Firebird исправьте пожалуйста.

А чем лучше/хуже MS SQL того же постгрес? Ну кроме разве что у ней лучше интеграция с М$ софтом.

Что-то слишком провакационное утверждение, особенно учитывая что в самом тексте написано : """And for the foreseeable future, proprietary databases will be the platform of choice for the largest mission-critical database deployments. """

> Fireird

> Проверено: Shaman007 (*) 22.12.2007 18:46:08

~_~

первыми двумя буквами в аббревиатуре: они означают что за нее придется заплатить.

Глупости. Однозначно. Даже лениво вступать в дискус относительно ms vs my. Oracle наше все!

субд вообще обречены, с повсеместным переходом с магнитных хардов на электронные быстрее будет прочитать и распарсить файл с диска, нежели тащить коллосальный костыль в лице субд

проприетарныесубдкапец?

Epic fail

флеймопровокация не удалась

> Ну кроме разве что у ней лучше интеграция с М$ софтом.

И хуже интеграция с *nix. FreeTDS ужасно глючит, долго держащиеся коннекты зависают, транзакции обрываются и т.д..

А еще у оффтопикSQL сильные проблемы с видами. Редактируешь структуру любой таблицы, забываешь обновить/пересоздать вид и поля в буквальном смысле «съезжают». Один раз из-за такой элементарной забывчивости в поле имени попали данные пароля, и хорошо что они показывались только легитимным пользователям и все это творилось только несколько часов...

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

Что ожидать от блога расположенного на сановском сервере? Только того, что там будут расхваливать PostgresSQL, который поддерживает Сан.

> SQL единственный небыдло язык

Кстати, не совсем небыдло, местами у него есть отнюдь не красивые стороны. Хотелось бы Tutorial D все же.

>>быстрее будет прочитать и распарсить файл с диска

Файловая система - это костыль. Недоделанная иерархическая СУБД.

>нежели тащить коллосальный костыль в лице субд

гыгы, за целостностью данных и логикой (триггеры и иже с ними) тоже файлы следить будут? =)

+1 Даёшь *fs капец!

Oracle - дорогой.

Firebird Нормальная СУБД.

Хорошая новость.

И кто кроме оракла умеет делать в тексте поиск с оператором NEAR ? (когда одно слово находится не дальше чем на N слов от другого). Для меня это критическая фича. Mysql этого не умеет. PostgreSQL, Firebird насколько я понимаю тоже.

Я написал свою собственную систему индексации и поиска для этого, с такими ценами оракл потерял меня как покупателя :), так что обречен :)

Гы-гы, а чего еще ожидать от блога, на санковском сайте??? Иссесно там будут пиарить трехзвенный подход, когда вся логика лежит на аппсервере, а базу проще всего поставить бесплатную MySQL или PostgreSQL и использовать исключительно как хранилище данных без всякой логики. Ну а санкам заплатить денег за саппорт аппсервера (см. на пиар glassfish), который у них есть, а не ораклу/межделмашу за саппорт их базы.

Вроде была же уже новость, что постгрес отстаёт от оракла всего на 10-15%%. Так что да, проприетарные СУБД обречены на капец.

за целостностью данных нормальные фс и так следят, а логика в базе не нужна

>> нежели тащить коллосальный костыль в лице субд

> гыгы, за целостностью данных и логикой (триггеры и иже с ними) тоже файлы следить будут? =)

Следить будет программист который не забудет локи поверх файловой системы создавать. Например я так делаю (тот анонимус - не я). Триггеры в моем проекте нафиг не нужны, а вот базы данных без вышеупомянутого оператора NEAR идут на х.

Мне почему-то кажется, что NEAR можно эмулировать с помощью регекспов. Иля я не прав?

>anonymous (*) (22.12.2007 19:11:31) >субд вообще обречены, с повсеместным переходом с магнитных хардов на >электронные быстрее будет прочитать и распарсить файл с диска, нежели >тащить коллосальный костыль в лице субд

Очередной обкурившийся XML-ем. Каким образом определять конец строки ты подумал? while !eol ?

> Файловая система - это костыль. Недоделанная иерархическая СУБД.

Есть рабочие альтернативы ФС?

>Oracle - дорогой.

>Firebird Нормальная СУБД.

Не надо ляля.... на больших объемах мало что спасает, и если для вас критичны производительность по отношению к надежности и объему данных, то Вы не поставите Firebird, MySQL на терабайтные БД.... тупо захлебнутся :(

2szh >Следить будет программист который не забудет локи поверх файловой >системы создавать. Например я так делаю (тот анонимус - не я). Триггеры >в моем проекте нафиг не нужны, а вот базы данных без вышеупомянутого >оператора NEAR идут на х.

Офигеть. Что-бы значит сделать горячий бэкап надо отрубить твою перделку? Об инкрементальном бекапе страшно тебя и спрашивать

> Мне почему-то кажется, что NEAR можно эмулировать с помощью регекспов. Иля я не прав?

Да, можно поискать AND-ом, а потом в нем искать регекспами. Только скорость поиска при этом будет ниже, чем при индексации с near. Могли бы ее где-нибудь еще кроме оракла сделать к 2007 году, ничего сверх сложного.

> за целостностью данных нормальные фс и так следят, а логика в базе не нужна

Не так они следят как надо. Я уж думаю скоро наступит прозрение (а так же надо будет девать куда-то лишние мощности :) и PostgreSQL вполне себе надёжная база) и ФС будут строиться над нормальными БД, благо тестовые проекты уже имеются.

*ехидно так...

s/Fireird/Firebird

>за целостностью данных нормальные фс и так следят, а логика в базе не нужна

клоун убил наповал =) лежу и плачу =))))

>>субд вообще обречены, с повсеместным переходом с магнитных хардов на электронные быстрее будет прочитать и распарсить файл с диска, нежели тащить коллосальный костыль в лице субд

o_O слов нет...

> А чем лучше/хуже MS SQL того же постгрес? Ну кроме разве что у ней лучше интеграция с М$ софтом.

Ну например с разными версиями друг-друга у MS SQL огромные проблемы. А ещё у MS SQL проблемма с интеграцией в неё данных.

> который не забудет локи поверх файловой системы создавать.

Ога, сначала локи, потом апгрейд механизма локов, потом ишо немного расширим функционал и в итоге все это выльется в очередную СУБД =)

Хотя не спорю, во многих местах СУБД попросту не нужна, либо что-то вроде сикуельлайта вполне подходит.

Давно пора, как водрузить 64 bit энтырпрайз оракл 10g на 64 бит убунту это просто атас. Пинание его 32х битных хвостов меня несколько утомило, потому я больше с этим ничего общего иметь не хочу. Привет постгрес.

> Я уж думаю скоро наступит прозрение (а так же надо будет девать куда-то лишние мощности :) и PostgreSQL вполне себе надёжная база) и ФС будут строиться над нормальными БД, благо тестовые проекты уже имеются.

Велосипед! ФС в качестве файловой системы была на многих системах. Особенно этим всякий big iron от IBM и им подобным грешил. И все сгинули.

Желание построить файловую систему над DBMS (WinFS anyone??) - это какая болезнь, эпидемии которой случаются в разных средах разработчиков :-)))

>На рынке баз данных время перемен. Главным укоренившимся компаниям-проиводителям бросают вызов быстро достигшие успеха OpenSource - проекты: MySQL, PostgreSQL, Fireird. Еще одна статья по поводу обреченности проприетарных СУБД (англ.)

А Оракл то и не знает)))

Тупая статья. Современные "большие" БД типа Oracle'а или MSSQL примерно на 10 лет опережают по фичам открытые БД.

Например, нормальный ответ Oracle RAC'у пока есть только у MySQL (и то, половинчатый). Вообще, фичи типа горизонтального разбиения, репликации, live update'а - пока у OpenSource'а очень страдают.

Разве что только полупроприетарный MySQL движется в сторону этих фич с достаточной быстротой.

> PostgreSQL вполне себе надёжная база

Возможно, только всеравно везде(читай, где сложной логики не нужно) ставят mysql. По сравнению с уе^W глючным собачьем мускулевским query browser постгресовская админка выглядит как MS SQL Mangment Studio, не меньше. А за синтаксис SP мускулевцам вообще яйца вырвать надо, вместе с позвоночником.

Впрочем, я всегда считал, что разработчики мускуля - индусские геи.

>субд вообще обречены, с повсеместным переходом с магнитных хардов на электронные быстрее будет прочитать и распарсить файл с диска, нежели тащить коллосальный костыль в лице субд

a в каком формате где чё хранить и как выдавать надо велосипед с подобием SQL приделать? а репликацию будем rsync'ом? :) бугага

> А Оракл то и не знает)))

Знает-не знает, а оба транзакционных движка (BDB и InnoDB) на всякий случай из под MySQL'я купил. Из под PostgreSQL не купил наверно только потому, что там неясно что именно покупать, весь код под BSD.

anonymous (*) (22.12.2007 20:31:15)

>Давно пора, как водрузить 64 bit энтырпрайз оракл 10g на 64 бит убунту >это просто атас. Пинание его 32х битных хвостов меня несколько утомило, >потому я больше с этим ничего общего иметь не хочу. Привет постгрес.

Твои проблемы на Metalinke разжеванны уже как два года. Нет бабла на Metalink? Верю. Но то, что нет способности прочитать, что 10g EE не сертифицирован для юбунты говорит о том, что Оракл тебе нафиг не нужен.

> Велосипед! ФС в качестве файловой системы была на многих системах. Особенно этим всякий big iron от IBM и им подобным грешил. И все сгинули.

Всё новое - хорошо забытое старое. Ранее не было PostgreSQL и дешёвого железа для экспериментов :)

> Офигеть. Что-бы значит сделать горячий бэкап надо отрубить твою перделку? Об инкрементальном бекапе страшно тебя и спрашивать.

Инкрементальный бекап у меня автоматический, т к в лог идут все запросы изменений, аналог лога sql запросов. Отрубать ничего не надо, чтобы получить доступ к последней версии надо получить лок и тут же его отдать, т е ~0.01s , не мерял.

>> PostgreSQL вполне себе надёжная база

>Возможно, только всеравно везде(читай, где сложной логики не нужно) ставят mysql.

Алексей Борзов http://www.inp.nsk.su/~baldin/PostgreSQL/Alexey/Alexey.html объясняет это отсутствием порта на win32. Сейчас этой проблемы нет и через какое-то время ситуация устаканится.

>> Велосипед! ФС в качестве файловой системы была на многих системах. Особенно этим всякий big iron от IBM и им подобным грешил. И все сгинули.

> Всё новое - хорошо забытое старое. Ранее не было PostgreSQL и дешёвого железа для экспериментов :)

Ниубидил.

- У Microsoft WinFS team было и железо, и, по слухам, код SQL Server'а и 10 лет времени и так ничего и не родили.

- Приведи пример операции, которую ФС на PostgreSQL делала бы лучше чем например ext2.

> Тупая статья. Современные "большие" БД типа Oracle'а или MSSQL примерно на 10 лет опережают по фичам открытые БД.

Не раскрыто чем MSSQL таки лучше или только тем, что в данном предложении идёт за Oracle. Чем блокировочник может быть лучше версионника?

проприетарное ПО обречено. все и сразу.

> Не раскрыто чем MSSQL таки лучше или только тем, что в данном предложении идёт за Oracle. Чем блокировочник может быть лучше версионника?

Тем, что не тратит память на версии, которые все равно не будут нужны ?