Я долгое время работал с Оракл, потом немного с Постгре.
Сейчас попытался начать работать с MySQL 5.0.
На КАЖДОМ шагу сталкиваюсь с какими-то проблемами, которые как оказывается просто не реализованы в MySQL. Я в шоке. Может быть, я чего-то недопонимаю, но меня поражает, что люди вообще сравнивают MySQL с  другими БД и работают с ней и даже многие не плюются и оценивают MySQL как очень хорошую БД.

Ниже я привожу список проблем норнмального решения для которых в MySQL я не нашел. Прошу объяснить мне что я дурак либо объяснить, как вообще можно работать с такой БД и быть довольным ею. Спасибо.

a) Если я делаю varchar  как  not null , то оно автоматом получает значением по умолчанию пустую строку. Нормальные БД генерируют ошибку при попытке вставить запись NULL значение в NOT NULL текстовое поле.

b) Если я делаю update users set status = 1 where id = 100 и к моменту выполнения запросто 100-й юзер уже имеет статус = 1 , то affected rows = 0.  Это ведь бред. Так не работают нормальные БД. Как я должен знать сколько записей попало в условие where?

c) Отсутствует механизм пользовательских  exceptions

d) нет вообще constraints

e) нет возможности объявить переменную типа "запись" table%row types, которая состояла бы из нескольких полей и  соответствовала бы записи в заданной таблице

f) Невозможно переименовать поля которые используются в FK

g) Если вставляю NULL в числовое NOT NULL поле - вообще нет никакой ошибки. Просто запись не вставляется.

h) Если insert вызывается из sp или fn  и он fails - нет никаких сообщений об ошибке.

i) dynamic sql is not allowed in stored procedures

j) Отсутствуют sequences, если лишь автоинкременты.

k) функция не может возвращать rowset

l) при ошибке в синтаксисе сообщенеи об ошибке не дают четкого представления о природе происхождения ошибки. Почти всегда 'invalid syntax at near'

m) Если объявлено view как select * from нескльких таблиц, в каждой из которых есть поле id, то это вызывает  'Duplicate column name id'. Приходится перечислять все поля вручную.

n) Нет возможности использовать процедуру, возвращающую набор записей в подзапросе.

Похоже просто тролль. Человек явно не проверял то что пишет, а насобирал по инету всякого... Часть - ограничения описанные в документации, часть просто FUD

Это сообщение отредактировал(а) Бонифаций - 28.10.2008, 15:40

mysql> create table `ntest` (
    -> `v` varchar(10) NOT NULL,
    -> `i` int(11) default NULL
    -> )ENGINE = InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.16 sec)

mysql> insert into ntest (i) values (1);
Query OK, 1 row affected, 1 warning (0.10 sec)


Возможно какие-то настройки??


По второму пункту согласен. Ошибка у меня не приходила в php. Видимо грабли где-то между mysql & php.


ВСЕ пункты на ЛИЧНОМ опыте.



Что ж это за БД такая, в которой столько ограничений?! Не понимаю, в чем секрет, что на нее не ругаются, используют, на равных сравнивают с другими БД. 
Ведь просто сплошные ограничения...

grep2, не нравится - не используй. 
Mysql для чего делали ? что бы быстро делать select * from a where b = c;
вот так его и используют.

Если нужна продвинутая БД - платите деньги за Оракл. 

Ну или пострегсс.. но я думаю там тоже будут свои особенности.


Кстати в дополнение к вашим пунктам:

Работа с XML в MySQL - просто курам на смех. Лучше бы уже вообще никакой не делали. (Речь об ExtractValue)

каждому свое...  Mysql легкая, бесплатная испольщуется повсеместно в WEB-е . Не будешь же ты для какого то дешевого Online-shop-а который приносит в месяц до 10 тыс прибыли использовать Oracle или MS....
Плюс если посмотришь книги по WEB-у и PHP везде идет Mysql ....
А то что куча ограничений - да есть, но ведь банк бесплатный и программистов у него не столько сколько у Oracle, MS или IBM, не могут они такую конфетку сделать, уж прости...
Это в принципе было мое ИМХО   

PostgreSQL тоже бесплатный. Но ведь он по функционалу намного ближе к ораклу.
Собственно почему я написал вопрос. Потому что я хочу для себя понять то, чего я сейчас не понимаю.

Почему при таком количестве ограничей MySQL на равных сравнивают с другими БД, тем же бесплатным PostgreSQL ? Почему есть его сторонники и почему на нем иногда пишут большие проекты типа Фейсбука? 

Судя по моему опыту, MySQL и PostgreSQL  просто несравнимы. Это БД разного класса. Полагаю, я где-то ошибаюсь. Но где?

ладно. посмотрим, что имеем.
расширяемость. производительность. простота использования(включим сюда простоту разработки и простоту сопровождеия). поддержка(коммьюнити, литература).
возможно, что-то упустил.
пройдемся по пунктам(в произвольном порядке).
1. коммьюнити - источинк знаний и идей; способ решения большинства проблем - почитать книгу или спросить на форуме. СУДБ может быть сколь угодно прекрасной во всех отношениях, но если некому ответить на твой вопрос - завязнешь в основах и не пойдешь дальше. получается, вроде бы, замкнутый круг - никто не знает -> никто не использует -> никого не интересует -> никто не знает. но, в принципе, это больше похоже на снежный ком: приложил немного сил - и сообщество растет экспоненциально... для сравнения: результат поиска статья mysql и статья postgresql. в данном случае я не хочу показать, что у postgresql слаобе русскоязічное комьюнити(mysql пока в этом плане выигрывает). я хочу подчеркнуть то, что про mysql вполне можно сказать: "ответ на практически любой вопрос ты получишь". потому как есть, где искать и есть, кому отвечать.
2. производительность, конечно, некий сферический конь в вакууме, но, все же, если бы было слишком уж тормознуто, то не использовали бы эту СУБД только по причине распространенности... нет. а так - всяких (синтетических) тестов в интернете навалом. в части из них лидирует mysql, в части - postgresql, oracle, mssql опять же... 
3. расширяемость. хотите хранимую процедуру - пожалуйста. рекурсивную - ради Бога. функцию? вперед! UDF ещё и агрегирующую? пожалуйста, все в ваших руках! новый движок с поддержкой распределнности и p2p-based передачи данных между кластерами? пожалуйста. разрабатывайте. подключайте. на работе практически не отразится. расширяемость есть? кто скажет, что нет?
4. остался вопрос простоты. простота разработки  - возможность отладки(explain), логирования медленных запросов, достаточно вменяемые текстовые сообщения об ошибках. такие вопросы, как функция, возращающая набор или запись с несколькими полями, ньюансы использования динамического sql - вполне можно переложить на сторону клиента или реализовть несколькими ХП. с возможностью использовать подзапросы, union'ы с раздельной сортировкой для каждой части; поддержкой стандартов SQL коррелирует, но влияет слабо.
остаются вопросы поддержки. как раз сюда относяться претензии к constraints, переименования полей в FK и пользовательские исключения. допускаю,что здесь mysql вполне может проигрывать другим СУБД. "может", потому как именно с PostgreSQL я практически не работал, сказать не могу.
по-моему, выходит, что за исключением вопроса простоты поддержки, MYSQL если и не лидер, то вполне работоспособен. 
Хотел бы услышать возражения на собственные графоманские пируеты.
P.S. некоторые вещи мне вообще непонятны.

интересно, а как с твоей точки зрения это было бы логично разрулить? интересует вырожденный случай, когда в одноименных полях абсолютно разная информация. как поступать? автоматом выдать алиасы "id" и "id_1"(вроде, ms access так поступает...)? а какое поле будет каким?

то есть если считается количество попавших в условие where записей,то для того, чтоб получить количество реально измененных, я должен писать триггер, который посчитает мне количество измененных строк? почему бы для определения "сколько попадает?" не писать select-запрос? разве select не для выборки предназначен?

неужели даже в логе пусто?

неужели даже в логе пусто?

skyboy, 
1. - согласен, по MySQL намного проще ответ получить
2. - согласен. Производительность - то из-за чего юзают MySQL.  PostgreSQL тоже применим (skype на нем крутится), но MySQL - больше различных фищек. Репликация нормальная. Различные движки.. Например если вам надо с одной стороны поддерживать ссылочную целосность БД, а с другой  - быстро выбирать данные, то в MySQL можно сделать innoDB таблицу и реплики в памяти (memory engine) - будет летать. А Postgres - так тюнить нельзя (я не прав? могу быть.. но наш dba в этом меня уверяет)
3. - провал. Лучше вообще молчать про хранимки. Ладно хоть UDF есть - но и те - не сравняться с постгресовскими.
4. - cомнительно. ну да. логи. еще бы их не было. Древовидный explain как мне кажется - лучше...

Если не встает вопрос о нагрузке и репликации и есть выбор между MySQL и Postgresql - не вижу повода не выбрать второй.

Легксо можно найти еще. 

На вскидку - collations. У постгреса  один charset на базу. И что хуже одна collate  на весь (то что они называют) кластер.  
На вскидку еще - возможность innodb размещать данные без файловой системы. На raw partition. На вскидку еще - query cache. Еще - fulltext index.  ну и т.д. Можно еще grant у постгреса  вспомнить. В общем, для реальной работы mysql не хуже. 

 

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

 Я не помню какие имена получают поля в оракл и постгре, но там таких проблем и необходимости перечислять поля точно нет.




Во-первых, сам факт лишнего запроса - это плохо. Во-вторых, между запросом select и командой update данные могли быть уже изменены другим пользователем. В любом случае получить правильный affected rows - это очень даже естественное требование с моей стороны.



Да причем тут лог? Мне нужно кодом контролировать что происходит. Вызываю функцию из пхп и нужно видеть, что случилась ошибка. Отреагировать соотвествующим образом. Естественное требование.


По пункту g) при вызове напрямую из mysql ошибка все-таки видно, но из пхп этого не видно :(
Хрен могу понять почему.


Теперь по поводу оценок. Мой опыт подсказывает мне такое видение:
1. коммьюнити - возможно mysql немного впереди, но этот показатель сопоставим и не является критичным.
2. производительность - условно одинаковая (сколько людей столько мнений)
3. расширяемость - лично не сталкивался, но насколько могу судить - показатель сопоставимый. Условно можно считать примерно равны.
4. простота разработки и функциональные возможности. MySQL НАМНОГО уступает другим БД.

ИМХО для любого даже мало-мальски среднего проекта простота и функциональные возможности очень и очень важны. На фоне перечисленных мною минусов (причем это самые тривиальные из них) не вижу вообще возможности сравнивать эти БД. Уж простите меня, поклонники MySQL...

то есть, замечания Бонифация не видел? 

подумай логически - есть ли возможность обращаться к двум одноименным полям в отдельности? а если нет, то где больше контроля - когда ты явно указываешь пседоним для каждого "конфликтного" поля или когда алиасы раздаются автоматически по некоторому алгоритму?

а мне важнее количество измененных записей - если 0, то я, к примеру, не буду перепарсивать дерево. или перерисовывать окно. ну, как? подеремся?   

очевидно, что это проблема mysql. да?   

поставь последние версии обеих составляющих.
если проблема не исчезнет - напиши в саппорт PHP. 
если же просто любопытно - изучи С-интерфейс MySQL. и способ уведомления об ошибках. может, там какой недочет(в чем лично я сомневаюсь).

то есть ты считаешь, что в production-версии продукта фатальные ошибки в запросах - это нормально?  есть конструкции типа if exists, которые проверяют наличие. есть всяческие конструкции ignore/on duplicate key update, которые снимают проблему дублирования уникальных ключей. чего тебе не хватает? 

раз уж упомянул о PHP,то ответь: mysql_error молчит?

почему тогда не слышно про применение cache?
вообще, прикольно выглядит:

ага. "не сталкивался", но "намного уступает". "не читал, но осуждаю"   

прощаем! пиши ещё!   

Это было мое ИМХО конечно, но все же:
что есть в MySQL:
1) хранимки на SQL. Как говорит Бонифаций это соответсвует стандарту. Я не спорю, т.к. еще не добрался до него. Но ведь они не удобные! Смотри кучу потоков рядом. Нет expception, c курсорами криво, со сложными типами.. хотя жить можно, но с PL/SQL - намного удобней.
2) UDF MySQL - что мы можем ? писать функции и агрегатные функции. с API для UDF сейчас работаю - поэтому могу сказать - не слишком удобное. Практический пример: как сообщить юзеру о ошибке при выполнении UDF функции (на конкретной строке) ? 
3) с UDF API Postgresql побогаче: помимо функций, агрегаток, есть свои типы и операторы. 
4) В Postgres есть API для написания хранимок на куче языков (!) Как вам вызывать perl функции и SQL запросов ?

Интересно что весь разговор вокруг хранимок..

Никто и не будет спорить что хранимки в mysql еще слишком молодые.. Однако..

•  Основным назначением для DBMS на мой взгляд является надежное хранение данных и быстрая работа с ними. Поэтому, если
     выбирать приоритеты, скажем между хранимками или решениями которые увеличивают scalability сервера (partitioning например, репликации и тд), то я полностью поддерживаю политику sun/mysql.
•  Существуют достаточно большое количество application server. И как правило их persistence systems генерируют простые запросы
•  Хранимки никогда не позиционировались как замена application servers. В качестве доказательства - вопрос - а как вы отлаживаете хранимки в том же postgres? Дебуггеры? code coverage при тестировании?

Про udf - если вы их используете, вы долнжы точно знать что делаете, иначе рискуете грохнуть весь сервер с непредсказуемыми результатами.. так что это не та вещь, которая  должна делаться  на коленке..

Насчет 



Особо радует как это реализовано. В каждой сессии будет свой интерпретатор perl. Особенно это забавно в случае явы..
Так что поиграться, или на слабо загруженном сервере - вполне. Для реальной работы - сомнительно.. Что доказывается кстати количеством 
решений с помощью этой фичи..

Бонифаций, так о том и разговор. Что MySQL - это крутой storage. Но не более.


Ну это ваш взгляд. Есть люди которые перекладывают всю логику на SQL и сильно экономят трудозатраты. 
Конечно про высокую производительность в таких случаях говорить не приходится. Это скорее для фоновых процессов. Однако когда нужно осуществлять сложные манипуляциии над сложными структурами данных в БД - app servers - suxx =)