The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Набор функций для упрощения перехода от MySQL к Po..."
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Набор функций для упрощения перехода от MySQL к Po..."
Сообщение от opennews on 18-Дек-05, 09:02 
Опубликован обзор (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.dev/opennews/art.shtml?num=6652

Cообщить модератору | Наверх | ^

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от гость email on 18-Дек-05, 09:02 
> В комплект входят недостающие в PostgreSQL функции...

А зачем, тогда, собственно переходить-то?!
Скорость там явно ниже, функций не хватает...

Cообщить модератору | Наверх | ^

3. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Аноним on 18-Дек-05, 11:42 
>Скорость там явно ниже,

Типичное заблуждение MySQL-щика. InnoDB по производительности не быстрее PostgreSQL, а MyISAM можно назвать read-only, так как он на локах всей таблицы при любой записи данных затыкается.

> функций не хватает...

В PostgreSQL эти средства есть, только обеспечивается другими функциями, это MySQL влез с "а мы пойдем другим, не совместимым ни с кем путем".

Cообщить модератору | Наверх | ^

8. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от nobody (??) on 18-Дек-05, 16:14 
>InnoDB по производительности не быстрее PostgreSQL,
>а MyISAM можно назвать read-only, так как он на локах
>всей таблицы при любой записи данных затыкается.

Но при MyISAM мускуль ведь быстрее постгреса?... А транзакции не всегда нужны.

Cообщить модератору | Наверх | ^

10. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Аноним on 18-Дек-05, 20:29 
>Но при MyISAM мускуль ведь быстрее постгреса?... А транзакции не всегда нужны.

Быстрее на чтении, если операции записи и обновления очень редки, как только среди SELECT появляется вкрапление INSERT или UPDATE, эта быстрота мгновенно улетучивается и превращается в тормоза. Частично может помочь delayed insert, без него вообще невозможно работать на MyISAM.

Cообщить модератору | Наверх | ^

14. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от mdv email on 19-Дек-05, 09:16 
хм. ;)
при MyISAM то на выборке может и быстрее, но вот ты попробуй проверить как оно будет жить при 150-250 апдейтов в секунду. на myisam с табличной блокировкой.
Cообщить модератору | Наверх | ^

23. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от nobody (??) on 21-Дек-05, 08:53 
табличные блокировки в myisam - это замена транзакциям в тех редких случаях, когда они нужны, но не часто. 150-250 апдейтов в секунду - это полным маразмом надо страдать, чтобы для этого использовать myisam с блокировками.
Я еще раз повторяю - транзакции (читай "блокировки") нужны далеко НЕ всегда. Кроме того, мускуль позволяет в одной базе держать таблицы разных типов, что дает возможность использовать преимущества всех типов. И плюс ко всему всегда можно изменить тип базы (одной командой).
Cообщить модератору | Наверх | ^

12. "InnoDB по производительности?!!"
Сообщение от Otto Katz Feldkurat on 19-Дек-05, 07:24 
InnoDB по производительности не быстрее PostgreSQL???

Типичное не подберу слова :)

InnoDB на тяжелых запросах ОСОБЕННО НА МАССОВУЮ ЗАПИСЬ при достаточном объеме RAM и достатчно большом InnoDB хранилище где-то раз в 10 уделывает одну и ту же самую MyISAM базу.

MySQL 4.0.26, 4Gb RAM, ibdata2=10Gig.

Летает, как пуля!

Ну и критическая масса установок уже набрана, сэры рыцари. NDB почем MySQL У Ерика купил? По 25 млн бакс. Ягоды определенно в ягодицах.

Postgres может вылезти только на полной совместимости по фронту.
Если они перестанут трещать о "Compatibility vs. porting", а просто позволят MySQL приложениям работать со слоном - все его поставят и попробуют.

А так, - в 60 лет в первый класс... У кого есть время на эти фокусы?

Cообщить модератору | Наверх | ^

24. "InnoDB по производительности?!!"
Сообщение от c0x (??) on 04-Янв-06, 20:18 
На больших базах, которые преимущественно лежат на винтах поскольку в буфера/кэш влезть не в состоянии просто физически, на самом деле разница в скорости сильно нивелируется реальностью (железом). Если конечно база это не plain text файл ;) Поэтому, наверное, немного более правильное решение просчитать для начала проект, объемы данных и темпы роста, возможность агрегирования/архивирования данных, а потом выбрать rdbms по средствам уму и сердцу. А не орать тут в форуме кто кого "уделывает".
Cообщить модератору | Наверх | ^

2. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от oxyum on 18-Дек-05, 10:27 
А вы сами скорость меряли?

Делать такие голословные утвержения не стоит.

Да и набор встроенных функций далеко не главное в базе данных. Куда важнее возможности по расширению.

Cообщить модератору | Наверх | ^

4. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от wsx email on 18-Дек-05, 12:04 
Вот сколько тестил PostgreSQL и MySQL. Могу сказать одно, MySQL в топку. Производительность намного хуже. Концепция не соответсвует на "Корпоративный" маштаб. А ПостгреСКЛ у меня выдерживает "огромные" объёмы и не жалуется.Темболее MySQL - изначально "учит" думать не верно.
Cообщить модератору | Наверх | ^

6. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от nobody (??) on 18-Дек-05, 15:13 
>Темболее MySQL - изначально "учит" думать не верно.

Например?

Cообщить модератору | Наверх | ^

5. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Port22 on 18-Дек-05, 13:26 
Я, лет 6 как перешел с мускл на постгрескл. Реально, группа разработчиков в последнем гораздо умнее, может так, чем в мускле. Нет такого "мотания" при исправлении сотни мелких ошибок....
Cообщить модератору | Наверх | ^

7. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Vlad (??) on 18-Дек-05, 15:32 
5 лет, полностью поддерживаю.
Cообщить модератору | Наверх | ^

11. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Nexus on 19-Дек-05, 03:29 
без обид - mysql для детей
Cообщить модератору | Наверх | ^

13. "для детей - ага, для SAP R3"
Сообщение от Otto Katz Feldkurat on 19-Дек-05, 07:32 
>без обид - mysql для детей


Cообщить модератору | Наверх | ^

22. "для детей - ага, для SAP R3"
Сообщение от Rattler on 20-Дек-05, 11:55 
>>без обид - mysql для детей

Ежели это про MaxDB (в девичестве SAPDB), то это совсем другая СУБД, самими SAP'ами сделанная. Вот только непонятно, будет ли MySQL AB развивать ее или подзабьют на это дело.

А собственно MySQL до недавнего времени только для детей и годилась. Очень много функций добавилось только в 5-ке (вложенные запросы, хранимые процедуры, вьюшки, триггеры и т.д.). Для простых задач, сводящихся к не менее простым выборкам это вполне подходило, но не более.

Cообщить модератору | Наверх | ^

9. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Ad email on 18-Дек-05, 18:51 
хоть на данный момент я и использую mysql, но планирую переходить на postgres. Одной из причин (многих) можно назвать нечитабельный код mysql. Прежде чем понять что к чему надо провести много времени, а код postgres и отформатирован привычно для меня и содержит вменяемые коментарии.
Cообщить модератору | Наверх | ^

16. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Demetrio on 19-Дек-05, 11:55 
А что такое нечитабельные код под базу данных Postgresql или Mysql?
Может что-то другое имеется ввиду?
Да и кто мешает пользоваться database abstraction library для  некритичных к скорости приложений, чтобы не заниматься этими "переходами"?
Cообщить модератору | Наверх | ^

20. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Ad email on 19-Дек-05, 18:03 
Имеется ввиду исходный код (сырци).
Cообщить модератору | Наверх | ^

15. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от AlexKiriukha (ok) on 19-Дек-05, 10:39 
Не знаю как кому, а мне сейчас с MySQL на PostgreSQL тяжеловато переходить. Наверное, играют привычки. Но тут другой вопрос возникает: на что можно сказать "вот как надо"? На Oracle (как лидера SQL)?
Cообщить модератору | Наверх | ^

17. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Tverd on 19-Дек-05, 12:11 
А мне вот SQLite3 хватает. И транзакции и скорость. Да еще и встраиваемость в приложения.
Cообщить модератору | Наверх | ^

18. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от qqqq on 19-Дек-05, 14:41 
"Средствов у нас хватает, ума у нас не хватает" (с) Матроскин :)
Cообщить модератору | Наверх | ^

19. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Port22 on 19-Дек-05, 15:00 
Последний, с Матроскиным 5+! :-)
Cообщить модератору | Наверх | ^

21. "Набор функций для упрощения перехода от MySQL к PostgreSQL"
Сообщение от Tverd on 20-Дек-05, 00:10 
Это ваше дело, что не хватает у вас :)
Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру