11 ms·
A list of reasons not to use MySQL: http://grimoire.ca/mysql/choose-something-else http://grimoire.ca/mysql/choose-something-else
by tragic 13y ago
A list of reasons not to use MySQL:
http://grimoire.ca/mysql/choose-something-else http://grimoire.ca/mysql/choose-something-else
- matwood 13y agoI was just complaining about mysql yesterday. Data truncation and silent failures should not be warnings! They should be errors. For example, 'str1' + 'str2' results in '0' and a warning in the default mysql config. A real rdbms should fail and tell you + is not for string concatenation in that system instead of running your query and perhaps overwriting your data and then warning you about it after the fact ('That query you just ran is broken, but we overwrote your data anyways - hey, here's a warning.'). Broken, horrible design.
- davidw 13y agoOne that has bitten my colleagues lately: Auto-increment primary keys get reused when, say, you create a record, then erase it, then pull the power plug. Mysql does not save the highest number used, meaning that you turn on the machine again, add a new record, and it has the same ID as the previous one. My very subjective impression is that every time I have anything to do with Mysql, sooner or later, some weird thing like that jumps out and bites someone in the ass.
- ericcoleman 13y agoThis effects InnoDB, but not MyISAM
- davidw 13y agoOk, but ... MyISAM is like racing down a hill on a bicycle with no brakes.
- smacktoward 13y agoThat's actually better than MyISAM, because at least experiencing it is thrilling...
- matwood 13y agoIf you are using MyISAM you might as well use a raw file system and assume you will lose your data at some point.
- laumars 13y agoI dislike MySQL as much as the next guy, but I'm not convinced what you've posted there is true because you can query the auto-increment number - in fact you can even define it in SQL when creating the the table. So MySQL does store the increment number (and it's not even some volatile runtime value that might get lost during power cycles as I've bounced enough dev machines to notice if that was the case).
- davidw 13y agoThe autoincrement number is stored just fine unless you erase the last record and then stop Mysql, in which case that last one is lost and reused when you restart Mysql. This can cause problems if, for instance, you did something with that record between the time it was created and deleted and used that ID... http://stackoverflow.com/questions/3718229/stop-mysql-reusing-auto-increment-ids http://stackoverflow.com/questions/3718229/stop-mysql-reusin... http://dba.stackexchange.com/questions/16602/prevent-reset-of-auto-increment-id-in-innodb-database-after-server-restart http://dba.stackexchange.com/questions/16602/prevent-reset-o...
- laumars 13y agoI've done exactly what you've described and never ran into that problem. Quite the opposite in fact, on some dev servers I've have to manually fudge the auto increment number because it didn't automatically reset to zero after I'd flattened the table. Like I said before, you can even create an empty table and define the auto increment to be 10000 if you wanted. So there is a persistent value that's stored. However I suspect the issue here is that I'm using a different MySQL engine to yourself.
- KingMob 13y agoYup. I encountered MySQL's silent truncation behavior back in 2000, and it blew my mind that a tool whose primary job is to safely store my data would ever delete some of it without my explicit command. Been a Postgres person ever since.
- sp332 13y agoI've never liked using MySQL (silent errors everywhere!), but it always seemed to be the most practical option. It would be really nice if Postgres is catching up in terms of features.
- davidw 13y agoFeatures? I've always thought of things like 'transactions' as the features I'm most interested in in a database. Granted, Mysql is catching up in terms of features like that, but for a long time, many people were using it without them (MYISAM).
- stephen_g 13y agoFor the most part, that happened long ago... What features are you using that aren't in Postgres?
- sp332 13y agoSpeed :) On one project we were able to get MySQL onto an embedded system where Postgres kept choking. Also replication is dead-simple with MySQL.
- Refefer 13y agoIt's amazing how fast you can go when you don't care about safety ;) That said, for all non trivial work loads, the latest postgres is quite the work horse, but of course requires some tuning for performance. We ended up switch to it after MySQL consistently sucked on smaller joins. Can't argue on the replication deal: it's a work in progress.
- ufmace 13y agoIf it's an embedded system, why not use SQLite instead?
- sp332 13y agoHonestly I wasn't part of that conversation on that project. I just heard rumblings from a distance :)
- davidgerard 13y agoThe only reason to use MySQL: that you have to run an application heavily optimised for MySQL, where any other DB is an afterthought (e.g. MediaWiki, Wordpress).
- marcosdumay 13y agoOn those cases, I normaly have better luck with the aftertought. Use MySQL when your application is incompatible with other databases. 99 times out of 100, that means that the database has inconsistencies, and the application depends on them, so be carefull when doing that.