MySQL 4.1.10a и 4.0.24 вышли

Чем он лучше Postrgres? Вон, лор на postgres сделан и не факт, что mysql потянул бы лор.

Разница в том, что о майскуле есть куча доков, и хорошая книжка. Для постгрепа нету ничего, на русском вообще по нулям. Хотя база совсем другая. Она часто используеться как "рабочий вариант". Т.е. на ней теститься приложение, потом отдаеться закачику, где посгреп меняетсья на oracle ;) На мой взшляд 8 посгрепа уже на уровне 7 oracle :) Что несомненно круто, т.к. оракле стоит далеко не 100 рублей ;)

мускул подходит для простеньких задач. а постгре - для серьезных.

C нагрузкой лора мускул справился бы на раз? это даже не нагрузка.
ведь изначально он разрабатывался для задач, когда выполнение select просходит на порядок чаще insert и update.

качество бд оценивается по наличию доков на русском? ))))
есть мнение, что людям, не способным прочитать доку на английском, нечего делать в IT сфере.

2catap: в книжный заходим?
http://shop.piter.com/book_about.phtml?id=978594723337&refer=4
http://www.symbol.ru/catalog/book/28817

> Для постгрепа нету ничего, на русском вообще по нулям.

Да, ну! Поищи хоть на сайте магазина Библио-глобус. (на озоне таки действительно нет)

http://shop.biblio-globus.ru/(cc2021vzlx2el3u5uykqzlz1)/search.aspx?do_quicksear ch=yes&quicksearch_value=Postgres&searh_field=keyword

Postgresql НЕ умеет репликацию нескольких серверов. MySQL умеет.

>Postgresql НЕ умеет репликацию нескольких серверов. MySQL умеет.

Кстати да. Поэтому postgresql можно юзать на простеньких БД, не очень большой критичности. Для важный и крупных проектов только MySQL.

> Для важный и крупных проектов только MySQL.

ххахахахахаххаа )))))

> C нагрузкой лора мускул справился бы на раз? это даже не нагрузка. ведь изначально он разрабатывался для задач, когда выполнение select просходит на порядок чаще insert и update.

Как раз insert и update довольно часто происходят на лоре.

> Поэтому postgresql можно юзать на простеньких БД, не очень большой критичности. Для важный и крупных проектов только MySQL.

Согласен. Ворочается база на 40 гигов на мускуле. База постоянно растет. Тьфу-тьфу, ни одного сбоя за более чем два года. В общем мускуль - поставил и забыл.

> Postgresql НЕ умеет репликацию нескольких серверов. MySQL умеет.

Кстати по этой самой причине mail.ru и yandex.ru отказались в свое время от постгресс в пользу mysql. Поделку postgres в сад.

http://www.postgresql.org/about/news.289
репликация в Постгре.

http://www.postgresql.org/about/advantages

Replication (non-commercial and commercial solutions) allowing the duplication of the master database to multiple slave machines.

> репликация в Постгре.

18.02.2005. Смешно :-) Вот лет за пять (как в mysql) вылижут, тады и посмотрим.

>Replication (non-commercial and commercial solutions) allowing >the duplication of the master database to multiple slave machines.

У меня рядом с домом на заборе ещё и не такое написано... А ты пробовал её делать-то? Эту репликацию в постгре. Всё, на что я наталкивался - это скрипты пупкиных вась со всего мира, и так толком ни один и не заработал.

http://www.postgresql.org/about/news.289 репликация в Постгре. anonymous (*) (13.03.2005 17:05:17)

так это не решение от производителей постгре, это сприпты японских пионеров. в сад, говорю же :-)

а что в 4й ветке мускула появились триггеры?

даже view нет.

> Кстати да. Поэтому postgresql можно юзать на простеньких БД, не очень большой критичности. Для важный и крупных проектов только MySQL.

http://benchw.sourceforge.net/benchw_results_open3.html http://www.phpbuilder.com/columns/tim20000705.php3?page=1 http://openacs.org/philosophy/why-not-mysql.html

ps а утренники вы устраиваете?

а им не надо. бОльшая часть "разработчиков" приложений под мускл не знают, что такое вью и уж тем более нормальная форма...

> NOTE: This Document was written in May 2000.

Ну да, ну да.. Это конечно аргумент

http://gborg.postgresql.org/project/pgreplication/projdisplay.php

http://pgcluster.projects.postgresql.org/

http://gborg.postgresql.org/project/slony1/projdisplay.php

http://commandprompt.com/products/mammothreplicator/

А где же книжке по 8 постгрепу, а? Желательно на русском :)

http://www.postgresql.org/docs/8.0/interactive/index.html

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

> Для важный и крупных проектов только MySQL.

А для важнейших и огромнейших - только gdbm.

Берешь Slony (www.slony.info) и читаешь документацию. Репликация на несколько серверов - без проблем, а вот multimaster планируется в Slony II.

mysql не умеет. как надо. А вот для PostgreSQL есть репликационный движок enterprise-уровня. Причём совершенно открытый.

Про надёжность постргри ходят легенды. Про надежность мускуля - анекдоты :)))

> Разница в том, что о майскуле есть куча доков, и хорошая книжка.

А какая хорошая книжка для mysql?

Поль Дюбуа?

ну причем тут постгре .. игрушечка

мускул - он для работы создан, ломовой скакун :)

> Про надежность мускуля - анекдоты :)))

Можно парочку?

>> Про надежность мускуля - анекдоты :)))

> Можно парочку?

....

Понятно :-)

вики,мускул и отключение электропитания. Чего то там некрасивое вышло.

>вики,мускул и отключение электропитания. Чего то там некрасивое вышло.

А постгре на распределённых базах отключение питания хорошо переживает? :)

> А постгре на распределённых базах отключение питания

> хорошо переживает? :)

:-) :-)

з.ы. гугл тоже почему-то не постгре выбрал, а мускуль :-)

> А постгре на распределённых базах отключение питания хорошо переживает?

MySQL. База данных обычный форум ~1GB. Забилась очередь запросов, децал не успел файрвол отреагировать на DOS. Через 5 минут все рассосалось, мускуль скинул часть запросов по таймауту, но в штатном режиме. Итог 5 таблиц в двух 2 БД с битыми ключами. Понятно что битые ключи это не смертельно, но такое поведение для нормального сервере IMHO не допустимо.

>Понятно что битые ключи это не смертельно, но такое поведение для нормального сервере IMHO не допустимо.

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

Но так, чтобы быстро и надёжно - этого обычно не бывает :) Приходится искать компромисс. Именно поэтому я выбрал mysql, а кто-то - постгре. Хотя это только один из факторов, были и другие - тогда постгре, например, UTF-8 не знал... кстати, как в постгре сейчас с вложенными запросами? Типа INSERT ... SELECT ...? А с созданием таблиц из результатов запроса? CREATE TABLE ... SELECT ...

> http://benchw.sourceforge.net/benchw_results_open3.html

Это просто фокус, проделанный грамотным иллюзионистом ;) Проблема в
специфически подобранных нерепрезентативных запросах + отсутствие
оптимизации запросов для mysql. Трюк постороен на игре с индексами.

> http://www.phpbuilder.com/columns/tim20000705.php3?page=1
> http://openacs.org/philosophy/why-not-mysql.html

Ну, а это старьё образца 2000-го года, не знающее о существовании
innodb. Можешь с читой совестью удалить эти две закладки.

> з.ы. гугл тоже почему-то не постгре выбрал, а мускуль :-)

это где ты такое узнал?

> это где ты такое узнал?

недавно интервью с кем-то из гугловцев проскакивало

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

> Это просто фокус, проделанный грамотным иллюзионистом ;) Проблема в специфически подобранных нерепрезентативных запросах + отсутствие оптимизации запросов для mysql. Трюк постороен на игре с индексами.

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

>мускл не может называться СУБД

А как оно должно называться? :) Какой класс у этого продукта, если не СУБД? Браузер? 3D-экшн? RTOS? :)

> серьёзные приложения с большими запутанными схемами

ну конечно, чем запутаннее, тем серьезнее :)

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

Схемы в приложении ? А если схемы запутанные и данных много и скорость имеет значение?

Бред в общем ... бизнес логика на сервере должна быть ...

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

> Бред в общем ... бизнес логика на сервере должна быть ...

хех ну где таких изготовляют - то mysql не база, а медиаплеер, то вся логика программы должна сидеть в базе, а прога только формы выводить и скринсейверы рисовать :) программы они разные бывают .. что если она данные из этой базы обсчитывает и результаты обратно записывает или выводит на экран в виде каких то картин от турбин самолетов, турбины тоже в базу вместе с бизнеслогикой засунуть? или в базу льются данные с датчиков или радара, а программа там ищет что-то интересное, разложения спектров и алгоритмы поиска тоже в базу засунуть, чтобы побыстрее считались? или не инопланетян ищем, а людей обследуем приборами ..

а еще у mysql такая лицензия что зарабатывать используя его можно только купив его. постгри при этом совершенно бесплатен.