111–120 of 164 posts
Earlier quoted context omitted.
How could you possibly not get the point? It's the first two (2) sentences "Considering MySQL? Use something else."
I used Postgres on a project and my main concern with it is that whatever GUIs were available were seriously lacking. Phppgadmin is awful. If you're really pushing its capabilities then there may be better solutions than MySQL but for bog standard applications and websites there is no alternative as far as I'm concerned.
Earlier quoted context omitted.
This is an ad hominem argument. His statements about MySQL should be judged on their own merits, regardless of the load times of his blog.
No, it's not. If you're going to be a performance authority about web technology, you should know how to configure the open-source and very well-documented code you are using.
There is no "web technologies" in the article, the term "web" is found only once (!) in the whole text.
I started 7 years ago with SQLite and still have all my sites and webapps running on that. Works wonderfully for me. Meanwhile I must have seen close to a dozen data storage systems become popular then be replaced by the next big thing, from MySQL to NoSQL and everything in between.
Earlier quoted context omitted.
In some of these cases MySQL is not being used as an RDBMS. And in most of those cases it looks like path dependency rather than a selection based on the merits of this or that database. Either way, this is actually an argument from authority ("So and so use Brand X, therefore Brand X has positive qualities Y"). I've sat in on presentations with DB2 engineers who bragged about the data centre IBM runs for UPS. ~12 bi…
It does invalidate claims that using product X is going to inevitably cause you huge problems once you "grow enough". I've seen a lot of places grow a lot while using MySQL, and the problems aren't really that different or more serious than in places using Postgres or Oracle. In fact, I know enough places moving from Postgres to MySQL due to growing pains.
What this article demonstrated is that MySQL will often give a false sense of security. That's not what you want from a system ostensibly meant to provide a number of important technical guarantees.
Multi-master is the one tickbox feature where MySQL is still clearly in front. Once the PostgreSQL team finish going about inbuilt multi-master in their usual meticulous, stepwise fashion (my WAG is that it'll land by 9.6), there really won't be any good technical reasons left to use MySQL.
I'm really not sure what to think of that article. On one hand side, I definitely agree with it and I've experienced many issues with MySQL. On the other, there are so many... strange points, it's hard for me to trust the author about the parts that are new to me. Things I've found weird so far are: - "my favourite example being a fat-fingered UPDATE query where a mistyped = (as -, off by a single key) caused 90% of…
So your whole post is nothing more than simple fanboy apologism.
I'm really not sure what to think of that article. On one hand side, I definitely agree with it and I've experienced many issues with MySQL. On the other, there are so many... strange points, it's hard for me to trust the author about the parts that are new to me. Things I've found weird so far are: - "my favourite example being a fat-fingered UPDATE query where a mistyped = (as -, off by a single key) caused 90% of…
The first thing you found wierd relies on selective quotation, you omitted "because of implicit string to integer conversion". The second is an apologist "but its well documented" defence. Your third point is changing the subject, he was criticising implicit type conversion, you again igore that. The fourth point is not about wanting to use the wrong syntax it is about MySQL acepting valid syntax and ignoring it. So…
Earlier quoted context omitted.
This is actually a pretty good summary of the whole article. The main point is that mysql works very well, by slightly modifying what you meant into valid statements and doing the best it can. And because what it does depends on the (hidden) type of the data as well as what you actually ask it to do ... it sometimes does things you didn't intend. It reads a lot like a static typing versus dynamic typing debate. It's…
This is not dynamic vs static. This is automatic type coercion vs explicit type coercion. This is not the same thing. Weak and strong typing are completely orthogonal to if the language is static or dynamic. Weak typing mean values will be automatically coerced into something it isn't, whereas dynamic typing only mean that you will get your error during runtime, not at compile time. Javascript is dynamic and weakly t…
At one end are systems which are demanding refuseniks, at the other are loosey-goosey, anything-goes systems. It is human nature to find the loosey-goosey system more attractive because it gives immediate positive feedback ("it works!") and conceals negative feedback ("what the hell does that error mean?").
The thing is that RDBMSes are ostensibly meant to be on a stricter end of that continuum. But MySQL directly subverts that presumption, which is the source of a lot of heartache in the longer run.
MySQL is the visual basic of SQL databases. Anyone can set one up and use it. The problem is that many non-technical people use MySQL and then think they know all about DBs. Ask them what ACID is, or about foreign key constraints. You'll get blank stares. If you know what those things are and value them, you probably don't use MySQL.
That aside, MySql does have transactions and it does have foreign key constraints. Innodb has been around for a long time, you know.
i read until the backup process and gave up reading through, for cold backups of online databases, you should use percona's extrabackup, its open source and free and works perfectly. http://www.percona.com/doc/percona-xtrabackup/ if you are using mysql a simple googling "hot backup mysql" will lead to that, i guess author didn't even bother to search. besides, you need to use replication and connect a couple of slave…
The problem with taking a backup from a MySQL slave is that the data is not guaranteed to be identical to the master, thanks to the subtle problems and peculiarities of the MySQL master-slave replication (some of them are described in the OP). For precisely this reason I install an automated job that periodically checksums the tables and sends the results to the DBA role.