Опубликован обзор (http://software.newsforge.com/article.pl?sid=05/12/15/1611251) целей проекта mysqlcompat (http://pgfoundry.org/projects/mysqlcompat), в рамках которого разрабатывается набор функций на SQL и PL/PgSQL для упрощения переноса MySQL приложений под PostgreSQL.
В комплект входят недостающие в PostgreSQL функции (например, работы со временем и строками), операторы и правила преобразований типов.
URL: http://software.newsforge.com/article.pl?sid=05/12/15/1611251
Новость: http://www.opennet.me/opennews/art.shtml?num=6652
> В комплект входят недостающие в PostgreSQL функции...А зачем, тогда, собственно переходить-то?!
Скорость там явно ниже, функций не хватает...
>Скорость там явно ниже,Типичное заблуждение MySQL-щика. InnoDB по производительности не быстрее PostgreSQL, а MyISAM можно назвать read-only, так как он на локах всей таблицы при любой записи данных затыкается.
> функций не хватает...
В PostgreSQL эти средства есть, только обеспечивается другими функциями, это MySQL влез с "а мы пойдем другим, не совместимым ни с кем путем".
>InnoDB по производительности не быстрее PostgreSQL,
>а MyISAM можно назвать read-only, так как он на локах
>всей таблицы при любой записи данных затыкается.Но при MyISAM мускуль ведь быстрее постгреса?... А транзакции не всегда нужны.
>Но при MyISAM мускуль ведь быстрее постгреса?... А транзакции не всегда нужны.Быстрее на чтении, если операции записи и обновления очень редки, как только среди SELECT появляется вкрапление INSERT или UPDATE, эта быстрота мгновенно улетучивается и превращается в тормоза. Частично может помочь delayed insert, без него вообще невозможно работать на MyISAM.
хм. ;)
при MyISAM то на выборке может и быстрее, но вот ты попробуй проверить как оно будет жить при 150-250 апдейтов в секунду. на myisam с табличной блокировкой.
табличные блокировки в myisam - это замена транзакциям в тех редких случаях, когда они нужны, но не часто. 150-250 апдейтов в секунду - это полным маразмом надо страдать, чтобы для этого использовать myisam с блокировками.
Я еще раз повторяю - транзакции (читай "блокировки") нужны далеко НЕ всегда. Кроме того, мускуль позволяет в одной базе держать таблицы разных типов, что дает возможность использовать преимущества всех типов. И плюс ко всему всегда можно изменить тип базы (одной командой).
InnoDB по производительности не быстрее PostgreSQL???Типичное не подберу слова :)
InnoDB на тяжелых запросах ОСОБЕННО НА МАССОВУЮ ЗАПИСЬ при достаточном объеме RAM и достатчно большом InnoDB хранилище где-то раз в 10 уделывает одну и ту же самую MyISAM базу.
MySQL 4.0.26, 4Gb RAM, ibdata2=10Gig.
Летает, как пуля!
Ну и критическая масса установок уже набрана, сэры рыцари. NDB почем MySQL У Ерика купил? По 25 млн бакс. Ягоды определенно в ягодицах.
Postgres может вылезти только на полной совместимости по фронту.
Если они перестанут трещать о "Compatibility vs. porting", а просто позволят MySQL приложениям работать со слоном - все его поставят и попробуют.А так, - в 60 лет в первый класс... У кого есть время на эти фокусы?
На больших базах, которые преимущественно лежат на винтах поскольку в буфера/кэш влезть не в состоянии просто физически, на самом деле разница в скорости сильно нивелируется реальностью (железом). Если конечно база это не plain text файл ;) Поэтому, наверное, немного более правильное решение просчитать для начала проект, объемы данных и темпы роста, возможность агрегирования/архивирования данных, а потом выбрать rdbms по средствам уму и сердцу. А не орать тут в форуме кто кого "уделывает".
А вы сами скорость меряли?Делать такие голословные утвержения не стоит.
Да и набор встроенных функций далеко не главное в базе данных. Куда важнее возможности по расширению.
Вот сколько тестил PostgreSQL и MySQL. Могу сказать одно, MySQL в топку. Производительность намного хуже. Концепция не соответсвует на "Корпоративный" маштаб. А ПостгреСКЛ у меня выдерживает "огромные" объёмы и не жалуется.Темболее MySQL - изначально "учит" думать не верно.
>Темболее MySQL - изначально "учит" думать не верно.Например?
Я, лет 6 как перешел с мускл на постгрескл. Реально, группа разработчиков в последнем гораздо умнее, может так, чем в мускле. Нет такого "мотания" при исправлении сотни мелких ошибок....
5 лет, полностью поддерживаю.
без обид - mysql для детей
>без обид - mysql для детей
>>без обид - mysql для детейЕжели это про MaxDB (в девичестве SAPDB), то это совсем другая СУБД, самими SAP'ами сделанная. Вот только непонятно, будет ли MySQL AB развивать ее или подзабьют на это дело.
А собственно MySQL до недавнего времени только для детей и годилась. Очень много функций добавилось только в 5-ке (вложенные запросы, хранимые процедуры, вьюшки, триггеры и т.д.). Для простых задач, сводящихся к не менее простым выборкам это вполне подходило, но не более.
хоть на данный момент я и использую mysql, но планирую переходить на postgres. Одной из причин (многих) можно назвать нечитабельный код mysql. Прежде чем понять что к чему надо провести много времени, а код postgres и отформатирован привычно для меня и содержит вменяемые коментарии.
А что такое нечитабельные код под базу данных Postgresql или Mysql?
Может что-то другое имеется ввиду?
Да и кто мешает пользоваться database abstraction library для некритичных к скорости приложений, чтобы не заниматься этими "переходами"?
Имеется ввиду исходный код (сырци).
Не знаю как кому, а мне сейчас с MySQL на PostgreSQL тяжеловато переходить. Наверное, играют привычки. Но тут другой вопрос возникает: на что можно сказать "вот как надо"? На Oracle (как лидера SQL)?
А мне вот SQLite3 хватает. И транзакции и скорость. Да еще и встраиваемость в приложения.
"Средствов у нас хватает, ума у нас не хватает" (с) Матроскин :)
Последний, с Матроскиным 5+! :-)
Это ваше дело, что не хватает у вас :)