всё ждём ждём когда на Объектно-Ориентные базы перейдёт человечество, но увы, большинство только к SQL приходит :(

видимо значимость простоты перевешивает значимость мощности, но ничё, скоро и *nix-ы перейдут плавно на XML-XQuery, там и файловая система станет системой объектов и пр.

Чуваки чувствуют тяжёлое дыхание слона на своей шее, скоро ведь появятся официальные беты PostgreSQL 7.5. Небось постараются объявить Мыскль 4.1 стабильным раньше него

Кстати "альфа" Мыскль 5.0 --- по странному стечению обстоятельств --- был объявлен практически день в день с релизом Pg 7.4

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

А уж как весело производительность страдает от "значимости мощности" ООБ...

Мы используем 4.1-alpha уже более полугода для серьёзной работы, и пока ни одной значительной ошибки не заметили. Раздражает лишь ракообразность в работе с кодировками...

> ...и пока ни одной значительной ошибки не заметили

а что будете делать, когда наконец заметите? ;

Попрошу поподробней где ОО базы значимей и мощьней SQLовых. Конкретных примеров хотелось-бы.

По сути reiser4 постоен таким образом что каждый файл, директорий и так дальше это объекты с определенным набором свойств, которые можно менять.

Например hash это свойство директория, а tail policy - свойство файла.

>> ...и пока ни одной значительной ошибки не заметили >а что будете делать, когда наконец заметите? ;

Обновимся :)

Хех

Это по моему у слоника от успехов дельфина уши сохнут и хобот узлом завязывается :)

Почитайте постгресовские листы сколько желчи выливается на MySQL, "мы лучше но нас никто не любит".... В MySQL mailing list такого нет да и Postgres там народ редко вспоминает.

Есть MySQL он работает и не жужжит.

а что такое серьезная работа?

ну как! вы как маленький! не слышали разве, что ОО и ХМЛ - это очень модно?

> Есть MySQL он работает и не жужжит. в сад! (жужжащий пользователь постгрескуел)

Всё ниженаписанное - ИМХО.
В том-то и дело что модно не всегда хорошо, а ОО базы это модно но ИМХО пока теория не за ООБ, а SQL на то и SQL что отделяет правила от структуры. Если скажем в объекте Работник мы захотим поменять принцип обсчёта зарплаты (например изменим коэффициент, а лучше целиком правило) то что в ОО будете делать перелопачивать всю базу? В SQL же переписывается только один запрос. Всё. А если поменять сам объект? Например удалить какие-то свойства, добавить новые? Тогда задача видимо усложняется ещё более. Напротив, в SQL нет ничего проще добавить/удалить пару таблиц.
Может быть кому-то покажется всё это чепухой, т.к. пока особо сериозно не занимался Б.Д. а только читал кое-что из теории, которя в основном хаяла ООБ, и восхваляла SQL. Видимо в этом что-то есть, так как ООБ не имеют под собой той надёжной теоретической базы что SQL - это раз. А два - энкапсуляция для логической структуры базы - жуткое зло. Т.к. приводит к аномалиям и прочей ерунде.
ООБ - не новый виток эволюции БД, каковым был переход от деревьев к таблицам, а лиш груда фич, да к тому-же плюс возврат отмершего анахронизма вложенности.
Если у кого-то есть что сказать объективное буду очень рад прочитать для общего развития. Общие фразы типа "рулит/сасет" прошу не писать.

На самом деле все зависит от того зачем используется база данных вообще. Часто вижу что база данных используется скажем так и вовсе не по назначению.

OO базы данных весьма хороши для сложно структурированных объектов в особенности динамической структуры которые на реляционную модель вообще грустно ложаться. Именно отсуюда и крики что всякие там вроде cache в 10 раз быстрее реляционных баз данных.

Для стандартного OLTP или DSS SQL базы данных это самое то.

Объясните популярно, чем ОО отличается от не-ОО. Так, для общего развития. Ведь складывается вспечатление, что ОО - это синоним для "бла-бла", а первейший и непременнейший признак "объектной ориентированности" - это неприятие строгих определений.

> Почитайте постгресовские листы сколько желчи выливается на MySQL, "мы лучше но нас никто не любит".... В MySQL mailing list такого нет да и Postgres там народ редко вспоминает.

Я почти повёлся, но потом вспомнил, мысклеводам не нужны списки рассылки; желчь выливается прямо в документации: http://dev.mysql.com/doc/mysql/ru/Compare_PostgreSQL.html

Особенно там умиляет сравнение возможностей старой версии PotsgreSQL c _планируемыми_ версиями мыскля.

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

> а теперь покажи это в английской версии доков .....

Ну так оно же там было? Это какой надо недетский комплекс неполноценности иметь, чтобы наезды на конкурентов в ДОКУМЕНТАЦИЮ вставить?!

> ну забыли убрать в одном из переводов устаревшую инфу и что?

Так, забавно просто. В русской версии сравнения фич (http://dev.mysql.com/doc/mysql/ru/MySQL-PostgreSQL_features.html) кстати до сих пор обещают в версии 5.0 фичи (представления, триггеры), которые в 5.0 явно уже не войдут. Они, наверное, из английской версии это сравнение выкинули, потому что задолбались всё время версии в этой таблице менять. В сторону повышения.

>>> ...и пока ни одной значительной ошибки не заметили

>>а что будете делать, когда наконец заметите? ;

> Обновимся :)

А с потерянными данными как? Или то, что в мыскле лежит, ценности не представляет?

а нельзя поподробнее? вроде как это одно из самых больших улучшений.. все вроде по стандартам.. что не устраивает?

Сижу на нём с 4.1.1alpha (около 5 месяцев)

Сервер нагруженный, около 50 тыс. mysql-запросов в час, загрузка 2x Xeon 1800 редко ниже 5% падает :)

В 4.1.1 был глюк с FULLTEXT INDEX. Т.е. просто осыпался периодически на интенсивных вставках, приходилось REPAIR TABLE делать.

В 4.1.2 глюк с FULLTEXT пофиксили, но по дефолту локаль клиента всегда, независимо от дефолтовой локали MySQL ил системы всегда была latin1. Приходилось каждый раз вызывать SET CHARACTER SET (что, в общем-то, правильно, но не во всех скриптах оно по дефолту есть)

В 4.1.3 это всё исправлено. Третий день - полёт нормальный :)

Вот бы ещё научиться определять на PHP в UTF-8 строка или нет, чтобы старые баги переезда ещё на 4.1.1 в некоторых записях автоматически исправить, сижу, ломаю голову :)

>> Почитайте постгресовские листы сколько желчи выливается на >MySQL, "мы лучше но нас никто не любит".... В MySQL mailing list >такого нет да и Postgres там народ редко вспоминает.

>Я почти повёлся, но потом вспомнил, мысклеводам не нужны списки >рассылки; желчь выливается прямо в документации: >http://dev.mysql.com/doc/mysql/ru/Compare_PostgreSQL.html

>Особенно там умиляет сравнение возможностей старой версии PotsgreSQL >c _планируемыми_ версиями мыскля.

угу русский перевод мануала по состоянию 2-х годовой давности во многом уже потеряло актуальность, но новичкам такой перевод - самое то..

в воту Postgresa есть что то подобное? в смысле мануалы там на скольки языках?

>Так, забавно просто. В русской версии сравнения фич >(http://dev.mysql.com/doc/mysql/ru/MySQL-PostgreSQL_features.html) >кстати до сих пор обещают в версии 5.0 фичи (представления, >триггеры), которые в 5.0 явно уже не войдут.

у меня противоположные данные. и триггеры и вью пишутся и пока еще сохраняют шансы попасть уже в каком то виде в 5.0

>>>> ...и пока ни одной значительной ошибки не заметили >>а что будете делать, когда наконец заметите? ;

>> Обновимся :)

>А с потерянными данными как? Или то, что в мыскле лежит, ценности не >представляет?

:)) Поподробнее.. чего, где и у кого теряется? вам люди уже несколько лет автивно говорят, что ни про какие потери никто и не слышал, а вы все про свое..

читаем внимательно mysql --help | grep i-am-a-dummy может это вам поможет..

Это цветочки. Оцени в какой попе postgres по-сравнению с sqlite:

http://www.hwaci.com/sw/sqlite/speed.html
Тоже скажешь, что на бедный postgres выливают желчь? Нет, просто он от
рождения убогий, и служит всем другим БД в качестве референс-модели
самой тормознутой и кривой реализации SQL-сервера ;)

2sad_spirit

Алексей, ну Вы адвокат классный конечно :) С Вашей любовью к Постгрес очень странно что Вы у них до сих пор не работаете. Кстати не ВМК заканчивали?-)

У постгреса точно также есть сравнение с MySQL. Если оно не включено в документацию, ну дык это ж не обязательно совсем, можно разместить и на "независимом сайте" типа sql-info.de :), и там популярно объяснить :) И ещё, представления в 5.0 будут... наверняка :)

> Это цветочки. Оцени в какой попе postgres по-сравнению с sqlite

Может хватит сравнивать ископаемые? постгрес 7.1.x, мускуль 3.x...

Вот кстати, кто-нибуть видел нормальный обзор-сравнение _текущих_ версий MySQL и PostgreSQL?

А в чём проблема? Старые версии сравниваются со старыми. Никому не
обидно.

ты его читаешь ничего нормальнее сделать не удается в соответствии с принципом неопределенности..

> Это цветочки. Оцени в какой попе postgres по-сравнению с sqlite: http://www.hwaci.com/sw/sqlite/speed.html

Ламо анонимное, хоть бы страницу дочитал, на которую ссылку даёшь. :)

> I am told that the default PostgreSQL configuration in RedHat 7.3 is unnecessarily conservative (it is designed to work on a machine with 8MB of RAM) and that PostgreSQL could be made to run a lot faster with some knowledgable configuration tuning. Matt Sergeant reports that he has tuned his PostgreSQL installation and rerun the tests shown below. His results show that PostgreSQL and MySQL run at about the same speed. For Matt's results, visit http://www.sergeant.org/sqlite_vs_pgsync.html

Ну да скляйт ваш мыскль ещё мордой по столу повозит: большая часть их целевой аудитории самостоятельный выбор сделать не может, и берёт то, что по умолчанию. А по умолчанию теперь скляйт.

> Алексей, ну Вы адвокат классный конечно :)

Спасибо тебе, Онанимный Доброжелатель.

> С Вашей любовью к Постгрес очень странно что Вы у них до сих пор не работаете.

Ну, сервер хакать мне квалификации не хватит. А так чем могу помогаю (флейм на LOR --- не основное, хе-хе).

> Кстати не ВМК заканчивали?-)

Кстати ВМК.

> У постгреса точно также есть сравнение с MySQL. Если оно не включено в документацию, ну дык это ж не обязательно совсем, можно разместить и на "независимом сайте" типа sql-info.de :), и там популярно объяснить :)

Нэ нада переводить стрелки. Пока мыскль --- единственный известный мне проект, где в ОФИЦИАЛЬНОЙ ДОКУМЕНТАЦИИ были наезды на конкурентов. С чем я вас, Онанимный Доброжелатель, и поздравляю.

А так можно ещё на разработчиков PostgreSQL совершенно безумный PostgreSQL HowTo навесить.

> И ещё, представления в 5.0 будут... наверняка :)

Ну, о том что их не будет, я слышал от Виктории Резниченко. Но, конечно, Человек, Который Боится Подписаться --- гораздо более авторитетный источник. Хе-хе.

> А в чём проблема? Старые версии сравниваются со старыми. Никому не обидно.

Тесты проводят, чтоб получить практические результаты, а не чтоб кому-то там было не обидно. А то давайте еще вспомним тесты на производительность SMP в linux 2.0.x и winnt4...

Ну вот у меня есть теперь регистрация, Вам легче?

> > Кстати не ВМК заканчивали?-) > Кстати ВМК.

А кафедру какую?-) Видать плохо учились, раз сил понять в чём же действительно разница между двумя движками нет :) (Если бы поняли - не стали бы ни качество одного хвалить, ни другого ругать).

Спор про наезды продолжать не буду, с адвокатом спорить бесполезно.

VIEWS в 5.0 скорее всего будут.

> VIEWS в 5.0 скорее всего будут.

Ну повтори это ещё раз 10. Глядишь, поверят.

> А кафедру какую?-) Видать плохо учились, раз сил понять в чём же действительно разница между двумя движками нет :) (Если бы поняли - не стали бы ни качество одного хвалить, ни другого ругать).

А Вас с ВМК с какого курса выперли?

Не понял. Какое отношение ошибка имеет к потери данных ? Может быть зависание крэш не правильные результаты - посмотрите на списков багов за последние годы - багов которые могут привести к потере с некоторой вероятностью - единицы.

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

Данные надо бакапить и уметь доставать из бакапа до текущего состояния log forward recovery в MySQL уже есть много лет...

Как SQL Lite которому несколько лет может быть "Reference" испольнением для других баз данных многим из которых десятилетия ?

Кстати про скорость они пишут правду.... но только ту правду которую хотят писать. Из за простоты sql-lite ряд простых операций там выполняется с меньшим оверхедам. Другим базам данных надо подумать как выполнять запрос так как есть альтернативы а здесь альтернатив нет так что что и думать.

Зато шаг в право шаг в лево....

>8MB of RAM
я готов аргуметированно доказать что на 8 мегах ОЗУ слоник отсос1т у дельфина по полной.:-)
я недавно компилял и запускал 7.3.4 на 486sx-50/20 - незабываемые эротические впечателния.;)
отшен полшой разниц с 1 гектарной машиной на каком-нибудь ath-xp-1900
где они могут пиписьками на равных померяться.
просто у каждой твари - своя ниша. и единственное что не менятеся - это ЛОРовские fw, оосбенно Pg vs мускул.;-)

> переход от деревьев к таблицам,
ну да, уменьшение возможностей под тупыъ клерков - это эволюция,
не порите чушь - иерархические БД - фактически основа всех современных более-менее из себя чего-то представляющих РСУБД - просто у них был в каком-то смысле неудобный API доступа.
сам несколько лет проработал с мампсом, особенно сильно ковырял MSM, так что сказки не рассказывайте про "отсталые нерялционные базы".

> динамической структуры которые на реляционную модель вообще грустно
на вышеупомянутый мампс они (динамические стурктуры) местами хорошо ложатся - но это ему не помогло.;)
"у каждого - свои недостатки":))

> Ламо анонимное, хоть бы страницу дочитал, на которую ссылку даёшь. :)
> I am told that the default PostgreSQL configuration in RedHat 7.3 is unnecessarily conservative (it is designed to work on a machine with 8MB of RAM)

Ай, а ты, ламо с погонялом, читал страницу, на которую линк даёшь? ;)
Где ты там увидел цифры по mysql? Их нет. Ну а цифоы sqlite vs postgres
сравнивал с первым тестом? Насколько офигенная разница там? А ламо с
погонялом в курсе, что mysql в дефолтной установке так же ограничена
по памяти примерно теми же восьмью мегами? Ась? Если уж взялся меряться
пиписками, то убери со своей увеличительное стекло для начала ;)

> Ну да скляйт ваш мыскль ещё мордой по столу повозит: большая часть их целевой аудитории самостоятельный выбор сделать не может,

Гм, опять ламо с погонялом понесло. В sqlite практически полностью
реализован SQL92 в отличие от mysql. Так что целевая аудитория sqlite
скорее та же, что и postgres.

> просто у каждой твари - своя ниша. и единственное что не менятеся - это ЛОРовские fw, оосбенно Pg vs мускул.;-)

Не, как-то скучно в этот раз...

Всё надеюсь, что появятся персонажи, которые напомнят, что MySQL используется в Google и NASA. Причём Google хранит в нём поисковый индекс, а NASA его на марсоходы установило. :)

> я готов аргуметированно доказать что на 8 мегах ОЗУ слоник отсос1т у дельфина по полной.:-)

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

> Не, как-то скучно в этот раз...

Дык мало веселишь народ ;) Мы всё ещё ждем, что ты ляпнешь чего-нибудь
посмешнее "потери данных" в mysql ;)

> А ламо с погонялом в курсе, что mysql в дефолтной установке так же ограничена по памяти примерно теми же восьмью мегами?

В Postgres'е до версии 7.4 по умолчанию памяти кушалось 512 кб.

В версии 7.4, из уважения к недоумкам, гоняющим "бенчмарки" с настройками по умолчанию, этот объём увеличили как раз таки до 8 Мб.

И ведь что интересно, почему-то бенчмарков с версией 7.4 я не видел...

> В sqlite практически полностью реализован SQL92 в отличие от mysql. Так что целевая аудитория sqlite скорее та же, что и postgres.

SQLite позиционируется как простая база для вебсайтов, оптимизированная под частое чтение и редкую запись. А уж какую часть SQL92 она реализует --- дело десятое.

> В Postgres'е до версии 7.4 по умолчанию памяти кушалось 512 кб.

Ну дык сами себе идиоты. Каков смысл так себя ограничивать, если по
любому загруженный в память сервер postgres отжирает много больше?

> И ведь что интересно, почему-то бенчмарков с версией 7.4 я не видел...

Ага, особенно, если не хотел их видеть ;) Взгляни:
http://people.ac.upc.es/zgomez/tpch-results.html

> SQLite позиционируется как простая база для вебсайтов,

Кроме твоего больного воображения это ещё где-то написано?

Прикол из tpc-h теста:

It is worth to say that mysql spent less time than postgresql loading the 1Gb database. Postgresql took approx. 2.5 days to load the entire database data.

2.5 дня на загрузку 1GB базы! LOL.

> Гм, опять ламо с погонялом понесло. В sqlite практически полностью реализован SQL92 в отличие от mysql. Так что целевая аудитория sqlite скорее та же, что и postgres.

ROTFL... я аж поперхнулся... однако =) Ты вообще видел что такое sqlite? Может еще скажешь, это та же целевая аудитория, что и у Oracke? =)