MySQL «на стероидах»

>Собственно после покупки Oracl'ом имеет смысл переходить всем на PostgreSQL.

+1
Хотя обьем русскоязычной документации покамесь не сравним с MYSQL

Странно, что ещё никто не упомянул о том, что собственно SQL-то уже своё отжил.

Сейчас в WEB всё больше набирают популярность NoSQL-хранилища, не так ли?

>Собственно после покупки Oracl'ом имеет смысл переходить всем на PostgreSQL.

Если вылечить конъюнктивит и посмотреть на мир не красным взглядом, станет очевидно, что существует множество задач, на которых постгри — тормозный оверкилл по сравнению с «массивом-на-диске» под названием MyISAM. так что всем на постгрес переходить точно не стоит.

Смотря для каких задач. Если для какого-нибудь интернет магазина изобретать nosql с самописным способом запросов, то это долбанешься пока напишешь и не факт, что будет быстрее чем sql вариант.

>Сейчас в WEB всё больше набирают популярность NoSQL-хранилища, не так ли?

Это очень специфическая вещь,особенно после sql.Нужно время для перестройки.

> Сейчас в WEB всё больше набирают популярность NoSQL-хранилища, не так ли?

Это только у тех, у кого БД сильно не влезает в один сервер

> А вообще, логика предпочтений по лицензии вполне очевидна: если это opensource вендор вроде redhat - он предпочтет gpl, если это проприетарщики типа apple - им bsd-like гораздо удобнее.

Для проприетарщиков у которых есть права на весь код выпускать свои наработки под GPL удобно, т.к. она ограничивает использование продукта конкурентами

осталось привести список проектов под bsd лицензий в развитии которых активно принимают участие крупные компании... и сравнить его со списком gpl/lgpl лицензированных проектов и компаний которые участвуют в этих проектах

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

>Сейчас в WEB всё больше набирают популярность NoSQL-хранилища, не так ли? Есть такая тенденция. Особенно, среди тех, кто не знает SQL.

«ля проприетарщиков у которых есть права на весь код выпускать свои наработки под GPL удобно, т.к. она ограничивает использование продукта конкурентами» а кроме Oracle такие еще есть?

>Поясни поглубже. Чем от этого будет плохо пользователям bsd-продукта?

тем, что какая-то контора под отдельные нужды сделала себе форк этого продукта? Что за бред вообще?

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

На вопросы оппонентов, как же можно использовать БД, например, без view'ов, разработчики отвечают в том ключе, что «все те, кому действительно серьёзно нужны view'ы - уже давно сидят на PostgreSQL или Oracle, это же касается и всех других продвинутых фичей».

И таки они правы.

Всем давно известно: нужна быстрая, но ограниченная по функционалу БД для веба - бери мускуль. Нужна БД для территориально разнесенной кластерной БД - бери оракл, для всего остального - постгри наше все.

И не надо из моськи делать слоника слона!

Легенды, легенды :)

MySQL - это не БД. Это недоразумение, произведенное на свет неосилятором. Глюки там не случайные - они там сознательно имплантированные. Потому что человек не знал, как правильно.

Есть такой продукт, MythTV. Он, по трагической ошибке, использует MySQL. В один прекрасный момент я решил почистить место на Media Server на основе MythTV. И обнаружил, что мааленькая базочка фильмов в MythTV занимает.. 170Gb. Беглый просмотр таблиц не выявил ничего даже близко похожего на эти обьемы. После backup-restore, который у MySQL текстовый и практически - регенерация базы, база сьежилась до 60Mb. Это у него логи так сделаны, в 300 раз больше, чем реальная информация.

Про глюки в реализации SQL можно писать поэму. Такое ощущение, что авторы MySQL не читали стандарты и не пытались работать с нормальными серверами.

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

А вы - лицензия, лицензия. Ни причем тут лицензия, его и так можно закапывать, вместе со всеми форками.

доки всегда лучше читать на языке разработчика - они полнее (%

>MySQL - это не БД. ..Потому что человек не знал, как правильно.

А никому «правильность» от СУБД не нужна. Разве что вашему научному руководителю и всяким там евангелистам. СУБД должна удовлетворять практические потребности.

мааленькая базочка фильмов в MythTV занимает.. 170Gb.
Это у него логи так сделаны, в 300 раз больше, чем реальная информация.

Если это binlog-и, то их автоматическое удаление настраивается. А для подобных встроенных решений в конфиге должны быть изначально отключены.

Либо вы просто не понимаете, что удаляя данные, файлы innodb уменьшить назад нельзя.

Либо это баг innodb, который внедрили относительно недавно и проявляется при слишком активной конкурентной работе. http://bugs.mysql.com/bug.php?id=57611 Маловероятно для такого приложения. Какая у вас версия mysql ?

Поддержка процедур и функций - это отдельная хохмочка

А ее и нет. Но как это влияет на основные функции mysql? Действительно, для тех, кто писал раньше для оракла с постгрессом, весь процедурный SQL в MySQL выглядит дико. Ну так НЕ ИСПОЛЬЗУЙТЕ ЕГО. MySQL это СУБД, а не хранилище кода.

Про глюки в реализации SQL можно писать поэму

Ну так и напишите. Вот сюда: http://bugs.mysql.com/

И мы узнаем глюки ли это или просто поведение сервера ломающее ваши привычки.

«Это весьма спорное утверждение. Крупным компаниям проще учавствовать в разработке под BSD-like лицензией, чем под GPL»

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

Хорошо если корпорация заплатит денежку и изымет потом код, а если код уже есть, то просто изымет.

Хотя GPL все равно ни от чего не защищает, ну разве что поделки на коленки. Пример жабы есть.

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

ну очень толсто.

После backup-restore, который у MySQL текстовый и практически - регенерация базы, база сьежилась до 60Mb. Это у него логи так сделаны, в 300 раз больше

а просто binlog удалить не судьба? или отключить его вообще, раз не нужен.

это к вопросу о неосиляторах.

>Ну, значит, в какой-то момент его не станет.

А успокойся мы уже превращаемся в http://ru.wikipedia.org/wiki/Бонобо