Я долгое время работал с Оракл, потом немного с Постгре.
Сейчас попытался начать работать с 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 =) 

Вот.. сейчас пишу UDF для извлечения куска XML по XPATH..
Какое API у MySQL для индикации ошибок функций:



т.е. если UDF обнаружила ошибку (например неверный формат) на какой либо строке, то мы ставим *err = 1
но MySQL(!) это инетерпретирует как возврат NULL для данной и последующих строк (или вообще пустой строки
если функция объявлена как не возвращающая NULL). Логично, не правда ли ?

Всем привет! Некоторое время назад я решил перевести комплекс MFC-программ с Sybase 5.0(очень уж старая) на MySQL. Принцип работы - устанавливается сервер, далее через мое приложение пользователь создает БД и работает с ней. Но до сих пор у меня это сделать не получилось. Моя задача создать из шаблона пустую БД со всеми процедурами и триггерами. Но в  MySQL не получается. Напрямую как в Postgres нет возможностей. Если через скрипты, тоже сложно. Одна из проблем заключается в создании процедур, с DELIMITER. Никак не получается создать из приложения процедуру через ODBC, а через libmysql.dll только по одной. Проблема с удалением-верхная таблица имеет две подчиненные с которыми сзязь del©, но эти таблицы связаны между собой del®. С этом случае как повезет, может дать удалить, а может и нет. Пробовал решить эту проблему при помощи триггера, не вышло из-за ограничений у триггера. Еще в одной версии надо ставить (;) в другой нет. Ходя СУБД уже много лет в эксплуатации, но мелочные проблемы остались. Вот и склоняюсь теперь в сторону Postgres-там этих проблем не наблюдал, а точнее я вообще никаких странностей не видел.
Хотя может MySQL не для этих целей.

CLIENT_MULTI_STATEMENTS не забыл поставить при открытити соединения?





Куда ставить? это ты о чем?



ну значит все впереди   , когда на первую граблю - кодировки и collate наткнешься - напиши..

При использовании CLIENT_MULTI_STATEMENTS функции стали записываться и таблицы, но не ссылки

их опять только по одной.
Да и в ODBC - CLIENT_MULTI_STATEMENTS не поможет. Просто переводимое приложение на ODBC работает, поэтому тестовый вариант хотелось бы на нем сделать. А насчет (;), я в форуме нашел, что в конце процедуры в одной версии надо ставить, в другой нет.

Бонифаций, а какие еще грабли PostgreSQL на вскидку вспомните ?
Там какжется какая-то нетривиальная репликация ?

Типа, в оракле и посгерсе их нет? Так ты их или не знаешь или они тебя устраивают. У любой вещи есть область применения. Если вещь (mysql) подходит для твоей задачи - используй. Если нет - используй другую. В противном случае можно и до забивания гвоздей микроскопом дойти.
В любом случае, mysql не самая простая софтина. И её документацию стоит изучить. Подводных камней там мнооого  К примеру, преобразование типов на лету и втихаря.


Не удобно штаны через голову одевать © не мой.
Тебе не удобно делать что-то конкретное? Т.е. какую-то задачу очень не просто решить в mysql но очень просто - в оракле? Тогда вычисляй стоимость неудобства и если она высока - покупай оракл. Если нет - используй то, что есть.

Вообще, спор «удобно/неудобно» довольно бестолковое занятие, какие-то сферические кони в вакууме. Речь может идти или о конкретных особенностях, или о решении конкретных задач.


Тебе это все нужно? Тогда используй PostgreSQL. Зачем полез в MySQL?


Ну так и используй его для этого. «Белаз - огромный грузовик. Но, блин, за грибами на нем ездить не удобно.» - ничего не напоминает?
Тебя, кстати, не смущает, что в оракле varchar не стоит использовать? 

Ну про Белаз сравнение не совсем корректное. Все автомобили должны ездить, заправляться доступным топливом и т.д. Далее уже есть тонкости грузоподъемность, скорость, удобство наконец. А когда в СУБД есть функции и они работают-этому нет оправдания. Тогда уж надо их вообще исключать. Я вот уже несколько месяцев с MySql мучаюсь(модернизирую структуру и меняю СУБД), уже структуру БД изменил, приложения переписал и т.д. Но вот постоянно возникает какая то неочевидная засада. Последняя из них - функции не записываются в файл при выполнении mysqldump. Вот таблицы с ссылками создаются, а функции нет. Это все равно что заехал на Белазе в карьер, загрузился, а оказывается задняя передача не работает и тебе предлагают на Камаз пересесть. Надеюсь, у меня хватит терпения добить этот проект и не менять СУБД, хотя в принципе мои требования должна выполнять любая реляционная СУБД.

Да ну! не записываются?? а документацию пробовал читать? например про ключик --routines ? Или про бэкап mysql.proc ?

Читаем

Ты так и не пояснил, на кой черт это тебе запонадобилось?


А это зачем?

бэкап mysql.proc - взять то можно, только вот правильно ли это, да и записывать как то сложно. А вот про --routines - не слышал, и гугле ничего не нашел, может быть и найдется решение, но они все так спрятаны. Это вот четвертая СУБД-где что-то большое делаю, но пока трудозатраты здесь на порядок больше и приходится огороды некрасивые городить. 


Просто очередная модернизация комплекса. Структуру поменял не из-за MySql, а из-за модернизации. СУБД у меня была очень старая-Sybase SQL 5.0. Модернизированный комплекс предполагает возможность работы в Win и Linux. У меня есть опыт работы с Postgres, хотел еще и MySql попробовать и выкатить в опытную эксплуатацию. Я это написал к тому, что уже успел сделать кучу работы(переписаны сотни запросов, форм вводов, расчетов и т.д.), а стопорюсь постоянно на какой то фигне-это и раздражает. Если придется бросить MySql-то в Postgres, я думаю, все сделать за несколько недель-структуру уже менять не надо. Но вот хочется все таки закончить в MySql.

 Честно говоря, задача не понятная. Судя по твоим постам, с PostgreSQL у тебя было бы все значительно быстрее. Тогда и надо было с ним работать. Или речь идет не промышленном комплексе, дома тренируешься? Ты готов потратить кучу времени непонятно ради какого результата. Ну, это не касается баз данных 

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


Дока, она не только в гугле   

Система уже много лет используется в разных городах. Главная задача была усовершенствовать структуру, сделать нормальный сервер БД и сделать конвертацию из старых БД. Времени и возможностей много разъезжать нет, поэтому многие функции администрирования БД хотел бы реализовать через свой интерфейс-чтобы пользователи смогли справиться. После всех структурных изменений-не так важно на какой СУБД работаешь, переход не будет болезнен, вот и захотел опробовать MySql. Мой кстати первый вопрос и был-стоит ли использовать MySql. 


Спасибо. Я вот это уже нашел-вроде работает.

В каком смысле спрятаны? Какой еще гугл?  Я же ссылку даже привел - в документации все прекрасно описано..

Я уже нашел и написал чуть выше