Рыжий Кот Хрен Рыжий Кот
Может он и быстрее на простых выборках, но отсутствие многих функциональных возможностей сводит на нет все его скоростные преимущества.

Сводит или нет зависит от задачи

Однозначно сводит. Скорость можно нарастить железкой. Функциональность - кодом. Стоимость кодирования выше стоимости железки.
Я очень люблю и уважаю MySQL, сам с него начинал и поддерживаю некоторые проекты, но с огорчением вынужден заметить, что функционально он сильно отстает от конкурентов. Тем, кто для самоуспокоения начинает сравнивать MySQL с Ораклом или другой настоящей СУБД, советую взять и изучить что-нибудь еще. Раз вы начали сравнивать, значит вам чего-то не хватает, что есть очень хорошо, вы не стоите на месте.
Изучить - не значит знать все операторы, а написать проект, чтобы было с чем сравнивать.
Ну зачем же так категорично... Было ведь сказано, "зависит от задачи"...
Так ведь и есть, скажем, для подавляющего большинства сайтов, которым уже требуется база, но нет каких-то особых наворотов, использование MySQL -- оптимальный вариант и по скорости, и по стоимости владения.
Ну вот действительно, чего может не хватать в таком варианте в MySQL 4.1, который уже GA?

Sad Spirit DocAlТак ведь и есть, скажем, для подавляющего большинства сайтов, которым уже требуется база, но нет каких-то особых наворотов, использование MySQL -- оптимальный вариант и по скорости, и по стоимости владения.

для "подавляющего большинства сайтов" (АКА хомяков) оптимальным вариантом является http://www.sqlite.org/%5D%D1%81%D0%BA%D0%BB%D1%8F%D0%B9%D1%82%5B/url]: как по скорости (на нагрузке только для чтения он быстрее мыскля), так и по стоимости владения: исходники в public domain , так что нет заморочек с лицензированием как у мыскля, нет сервера, следовательно не нужно его администрировать, всю "базу" можно таскать с места на место --- это один файл.

Ну, тут каждый сам выбирает для себя ограничения поля потенциального заработка... Вполне возможно, что заказы на 1 килобакс за месяц работы в свободное время для вас хомяки, не заслуживающие внимания, я же оцениваю это как неплохой приработок. На чём предлагаю и закончить с обсуждением "хомяков")
А sqlite -- штука действительно забавная, но о ней задумываться стоит только при невозможности использования... э... SQL-сервера в традиционном его понимании)
Sad Spirit
DocAl
Ну вот действительно, чего может не хватать в таком варианте в MySQL 4.1, который уже GA?

Хомякам хватит и скляйта, а более серьёзным сайтам может нехватать как минимум:
* представлений (VIEW)
* ограничений целостности (CHECK CONSTRAINT)
* хранимых процедур
По пунктам.
1. VIEW нету, факт.
Но на вебсервере, вообще говоря, и не следует хранить данные, для обеспечения безопасности хранения которых нужно предпринимать такие меры.
Ввиду не шибко большого интереса к этой опции, ещё и не имплементирована.
А многим разработчикам для начала неплохо бы привыкнуть использовать юзеров с различными правами в админских частях сайта и в общем выводе).
2. В InnoDB оно есть.
3. Опять хранимые процедуры!
Сколько топиков про них было -- везде основные аргументы их необходимости:
а) "А если на сервере что-то поменяется, что ж мне, на сотне клиентов бегать-исправлять?"
б) "А если завтра кто-то напишет клиентскую программу на другом языке программирования -- ему придётся все сложные выборки реализовывать с нуля."
Оба аргумента к БД сайта мало применимы. Какие предложите вы?

Sad Spirit
Чего задёргался-то? У меня в сообщении вообще ни слова про "заработок" не было.
Повторю ещё раз тезис: для простых сайтов эквипенисуально, какая база будет использоваться. Проект с бюджетом в килобакс подразумевает весьма незначительные нагрузки, кои выдержит любая СУБД, включая Access.

Не имея ни малейшего желания доверять стабильность собственной работы (во всех смыслах) производителю ПО, который не может даже обеспечить корректного отображения информации с собственного сайта в собственном же браузере, я рассматриваю лишь серверные продукты, работающие в FreeBSD в нативном режиме, в крайнем случае, в режиме бинарной совместимости с Linux. Насколько я понимаю, Access к ним не относится, и из рассмотрения исключается автоматически)
Sad Spirit
Ответ опять представляет из себя классический "зелен виноград". Коллега, в сложном веб-проекте могут понадобиться разные интерфейцы доступа (например веб-интерфейц и XML-RPC / SOAP). Проект может реально быть написан на нескольких ЯП. И "забыты" ещё стандартные ответы
в) Использование ХП позволяет повысить производительность.
г) Рабочее время программиста --- самый дорогой ресурс. Использование ХП может повысить производительность труда.


Встречный вопрос для мысклеводов: если ХП настолько никому не нужны, зачем их встраивают в следующую версию мыскля?

Могут. Могут и не быть. Мне кажется, не следует путать "может" и "обязан" ,)
Вроде бы, я нигде не говорил о вредности и принципиальной ненужности перечисленного.
Позволю себе напомнить, спор начинался с того, что ограниченная функциональность MySQL не в любом случае сводят на нет его скоростные преимущества. Собственно я не утверждаю же, что MySQL -- рулез для всего на все времена, лишь что существует отличная от нуля ниша применения СУБД, в которой применение MySQL объективно выгодно и оправдано. А то тут любят на вопрос, где можно его использовать, отвечать "нигде и никогда!".
Зачем же реализуют ХП -- ответ тривиален, для увеличения совместимости с ANSI SQL92, и расширения вышеупомянутой ниши применимости. Ну и всех прочих следующих из этого плюшек, типа увеличения производительности сервера и программиста и т.п. в _РАСШИРЕННОЙ_ нише применения. ,)

А пока этих плюшек нет, можно использовать MySQL в имеющемся виде там, где он есть (а он есть много где) и подходит, SQlite, где его возможностей хватает, а с альтернативой плохо, ну либо PostgreSQL, FireBird, Oracle по вкусу, потребностям и возможностям там, где MySQL не подходит. Опять же, я никак не утверждаю, что после появления вышеперечисленного, всем следует дружно переползти с других реляционных СУБД на MySQL,)