популярность MySQL нишевая, он юзается почти исключительно программистами на PHP. И тут три взаимосвязанных причины:
1) MySQL работает под Windows;
2) Поддержка MySQL в PHP (была) включена по умолчанию;
3) Низкий (в общем) уровень подготовки таковых программистов.

Кроме того, MySQL хотя и считается Open Source продуктом, но разрабатывается почти исключительно силами одной компании. У каковой компании есть деньги и специально обученные люди для засорения интернета трескучей пропагандой. Которая оседает в мозгах и затем повторяется пользователями как истина:

Макс М.1. в 75% случаев mysql вполне позволяет решать все проблемы, возникающие при написании сайтов.
в 100% случаев произвольный алгоритм можно запрограммировать для машины Тьюринга, однако на машинах Тьюринга сайты не делают. почему?

Макс М.2. на простых задачах (простенький магазин, форум, каталог и т.д.) он показывает неплохую скорость
1) по сравнению с чем? если на таких задачах использовать другие СУБД, будет ли существенное падение производительности?
2) где кончаются "простые задачи"? как узнать, "проста" ли моя задача?

Макс М.3. прост в администрировании
по сравнению с чем? в чём проще администрирование MySQL, чем администрирование
1) Access
2) Interbase / Firebird
3) PostgreSQL

Макс М.твоя страстная любовь к mysql мне известна :))
спорить с тобой не возможно

Дык а зачем со мной спорить? По-моему у нас с тобой совершенно одинаковые взгляды на основную причину популярности MySQL, нет? ;)

Остальные твои пункты --- на что я и намекал --- вполне подходят для описания PostgreSQL или Firebird, которые всё же объективно менее популярны среди веб-разработчиков.

ХренВ конце 90-х получила популярность технология LAMP - (linux-apache-mysql-php), без этой связки php и mysql раньше не рассматривались вообще.. (например мало кто помнит, что php можно использовать как отдельный самостоятельный язык, а не как модуль для apache).. \r
Слово LAMP, --- выдающийся пример вышеупомянутой трескучей пропаганды AKA buzzword --- что характерно, обязано своим происхождением именно "M", а не "L", "A" или "P". Вот интервью с Tim O\'Reilly :\r
интервьюI\'ve recently started referring to this platform as "LAMP" (Linux-Apache-MySQL-PHP/Perl/Python), after first hearing the acronym from Monty Widenius of MySQL a few months ago.\r
\r
А так аббревиатура имеет мало смысла: в России, например, куча хостингов использует не "L", а FreeBSD.\r
\r
ХренДа потому что в те времена альернатив не было. postgres до версии 7 (даже до 7.1) был неустойчив, и требовал периодической полной остановки работы для vacuum (без vacuum он показывает черепашьи результаты, неблокирующий vacuum тоже где-то с 7 версий появился), так что работы 24/7 не получалось.\r
Угу, угу. Типа, VACUUM требующий эксклюзивную блокировку таблицы (не надо ля-ля про "полную остановку работы") --- это отстой. А UPDATE для стандартного формата таблиц MySQL требующий того же самого --- это типа клёво.\r
Но это ведь не отвечает на вопрос, почему гораздо более качественный PostgreSQL 7.2+ не становится гораздо более популярным?..\r
\r
Хренwindows вообже не в тему. про php - поддержка mysql всегда была и всегда будет. Если вы хотите сказать сто новый php не будет поддерживать mysql...\r
Гы, надо было весьма пристрастно читать моё сообщение, чтобы сделать из него такой вывод.\r
Я говорил не про наличие поддержки (которая, естественно, будет), а про включение её по умолчанию, так что если раньше я всегда собирал php с ключом --without-mysql, то теперь этого делать не придётся.\r
\r
ХренТак как на старом компьютере даже после всякого выкручивания рук postgres-у, он просто не справлялся с нагрузкой (там где mysql легко работал с настройками по умолчанию).. \r
"Всякое выкручивание рук" == "редактирование postgresql.conf"? Дык давно и хорошо известно, что настройки postgres\'а по умолчанию --- полный отстой. Также известно, что если неумеючи поиграться с параметрами типа enable_seqscan, то можно загнать производительность просто в минуса.\r
\r
ХренЧто же касается "в чем проще" - например в документации. и postgres и firebird имеют значительно худшую документацию чем mysql\r
Ну с firebird и правда пока не всё хорошо, но вот по поводу postgres\'а --- в чём конкретно его документация хуже? А то если не будет конкретных примеров, то придётся процитировать кое-какие твои же выражения из треда про кластерную версию.

Marat_LВы будете смеяться, но мы используем MySQL в бизнес-задачах
Склад-учет-продажи-техпроцессы.
Во, это уже интересно. А почему был выбран именно MySQL?

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

Я же просил без "ля-ля". Вся база не блокируется, блокируется конкретная таблица. Для того же, чтобы она заблокировалась на "пару часов" (подразумевая нормальное железо и настройки), её размер должен быть в десятки гигабайт.

"Странно что ты сам не понимаешь разницы" между эксклюзивной блокировкой в те часы, когда база активно не используется (VACUUM), и во время пиковых нагрузок (UPDATE).

ХренТы эту блокировку при update начнешь хоть как-то замечать только при солидной загрузке большим числом клиентов.. Оправдывает себя такое конструктивное решение? Оправдывает.. потому что практика показывает что на большинстве задач mysql работает быстрее чем те RDBMS которые обеспечивают атомарность обновлений другими способами..


Так и запишем: "MySQL работает быстрее других RDBMS, если задача не связана с солидной загрузкой большим числом клиентов".

ХренЭто редактирование .conf, медитирование над postgres-овскими explain , переписыванием индексов под оптимизатор postgres, добавлением определенных хранимок (где надо было к примеру вставлять данные в несколько таблиц сразу) и тд..

Не, ну не наглость ли? Запускает оптимизированное под мыскль приложение и жалуется, что оно работает медленнее на совершенно другой СУБД. Радоваться должен: оптимизированное под постгрес приложение вообще на мыскле не запустишь.

ХренПожалуйста, вот тебе пример. Не мой, постороннего DBA, из мэйллиста:

Ну тут надо уточнить, что это не просто мэйллист, а мэйллист MySQL , где (в отличие от мэйллиста PostgreSQL) за такой базар отвечать не обязательно. Особенно хорошо эти слова смотрятся в контексте его "железных" доводов в пользу MySQL в том же треде:

посторонний DBA
First, MySQL is significantly faster than PostgresQL and Oracle.

Second, MySQL is also a simpler database to set up and configure.

Third, the documentation is better, and there are far more third party books out there.


Естественно , утверждения приведены без доказательств и противоречие в третьем утверждении (если документация настолько хороша, то зачем нужны все эти книги?) проигнорировано.

А вот на просьбу обосновать, как именно MySQL быстрее Oracle пошла пурга про тяжёлую настройку PostgreSQL :
посторонний DBA
Some of the parameters discussed include
random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, and
cpu_operator_cost.
...
Our database evolves fairly quickly (a few changes a month). We don't have time to re-test any query that might be affected by adding columns to a table, altering columns in a table, etc.

Это полнейшее гонево, т.к. перечисленные параметры зависят от железа , а не от схемы базы, что кстати написано на странице ссылку на которую DBA не постеснялся дать:
страница
For example, machines with very fast seeking disk arrays should probably lower the random_page_cost.


То есть для обоснования утверждения о том, что документация PostgreSQL хуже, Хрен ссылается на чувака из списка рассылки MySQL, который утверждает, что документация PostgreSQL хуже, не приводя полноценных обоснований.

Мы не будем пока считать Хрена треплом, пусть он вернётся сначала из командировки.

Хрендостаточно просто указать в _документации_на_постгрес_ место, где описано как настраивать эти параметры. Не "что это такое", а какие значения при каких обстоятельствах.. Ведь пользователь то имено об этом писал..
В документации на postgres честно написано
документацияNote: Unfortunately, there is no well-defined method for determining ideal values for the family of "cost" variables that appear below. You are encouraged to experiment and share your findings.
что именно ты предлагаешь разработчикам: выкинуть возможность задания этих параметров или написать от фонаря "какие значения при каких обстоятельствах"?..

ХренВместо этого вы стали доказывать что это неправильные пчелы^H^H^H^H^Hмэйллист и неправильный dba..
Вместо этого я показал, что не увидел описания конкретных проблем в документации (я не сомневаюсь, что они там есть, но сомневаюсь, что ты их знаешь), а лишь ссылку одного трепла на другое. Также я показал, почему я считаю "постороннего DBA" треплом.

Хрен(Это надпись плачет по вам уже давно, с тех пор например, когда вы утверждали что вот эти тесты были проплачены mysql и результаты икусственно подогнаны. Вот тут вот, чтобы освежить память).
Если внимательно прочитать, что я писал в том треде, то я не утверждал, что результаты подогнаны. Я утверждал, что тесты были организованы весьма странным образом. Что характерно, никто мне эти странности так и не объяснил...

ХренЯ свое мнение указал - документация на постгрес хуже организована и слабее прописана в деталях..

Нет, меня это подзадолбало уже. Мне твоё мнение без обоснования не интересно совершенно.

Кстати, я вот посмотрел: HTML документация PostgreSQL занимает 2,5 МБ в .tar.gz, а документация MySQL --- 1 МБ в .zip

Вывод: в доках MySQL содержится в 2,5 раза меньше информации. Так у кого слабее прописаны детали?..