MySQL - Do Not Pass This Way Again • Hacker News Board

Re: MySQL - Do Not Pass This Way Again

#161

Post by jacques_chester » Mon, Jan 28, 2013, 2:18 AM UTC

pippy wrote: post #159

jeffdavis wrote: post #144

Earlier quoted context omitted.

"PostgreSQL is pedantic with data insertion, almost to a fault." The PostgreSQL philosophy isn't about being "pedantic", but it is very different from MySQL. I assume that you have much more experience with MySQL; maybe you are trying too hard to use postgres in the mysql way rather than the postgres way? Personally, I don't think it's a good idea to migrate usually for this reason. The entire project development alw…

Yes I've been using MySQL in the PostgeSQL way. I learned to use databases using oracle databases, which is similar to MySQL.

> oracle databases, which is similar to MySQL.

How did you reach that conclusion?

Re: MySQL - Do Not Pass This Way Again

#162

Post by sadmysqluser » Mon, Jan 28, 2013, 2:29 AM UTC

jeffdavis wrote: post #155

sadmysqluser wrote: post #89

Earlier quoted context omitted.

If you would rather have faulty data than none when something's wrong with your application, then MySQL is your DB of choice.

I disagree that MySQL is a better choice when you have "faulty" data: * In postgres, you have PL/python (or PL/V8JS, or perl, or many other languages) to help you through the mess. For instance, you could write a canonicalization function to help you put the data into a more-queryable form. You can then even index on that function. * Powerful triggers might help with post-processing, or putting data into some queue o…

If you read pippy's statement carefully

  Also I have no idea what my users will do,
  and I'd rather have faulty data inserted than none at all.

you'll see we're in agreement - PostgreSQL's design and feature set makes it clearly superior to MySQL in preventing the spread of faulty data. But pippy would rather a garbage database rather than be slowed down by preventive measures. It's costing him development time after all...

By the way - thanks for all the great work on PosgreSQL range types.

Re: MySQL - Do Not Pass This Way Again

#163

Post by LaGrange » Mon, Jan 28, 2013, 11:11 AM UTC

jacques_chester wrote: post #160

LaGrange wrote: post #139

Earlier quoted context omitted.

But I didn't mean "grow" in exclusively performance meaning. I meant the whole package (as with growth the requirements for reliability also ultimately show up, at least in some parts of the business). Even my current job that involves a lot of MySQL has important chunks of Must Never Go Away Or Else data, with a lot of complex insert/update action going on them, and somehow it's working fairly well for us.

One of the persistent themes of the linked piece is that MySQL simply conceals many kinds of fault. "Somehow it's working fairly well for us" may be right. Or it might not. Either way, MySQL isn't going to warn you.

With default settings. I agree that keeping them as default is fairly bad, but in a growing scenario you need people who know the defaults very well anyway. After all, quiet database silliness is only one of the many ways you can quietly corrupt huge swaths of data.

It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are going to bite you. There is no escaping from knowing about the complexity, but you may escape from typing it out every single time.

Re: MySQL - Do Not Pass This Way Again

#164

Post by jacques_chester » Mon, Jan 28, 2013, 12:21 PM UTC

LaGrange wrote: post #163

jacques_chester wrote: post #160

Earlier quoted context omitted.

One of the persistent themes of the linked piece is that MySQL simply conceals many kinds of fault. "Somehow it's working fairly well for us" may be right. Or it might not. Either way, MySQL isn't going to warn you.

With default settings. I agree that keeping them as default is fairly bad, but in a growing scenario you need people who know the defaults very well anyway. After all, quiet database silliness is only one of the many ways you can quietly corrupt huge swaths of data. It's similar to Rails – the defaults save your time, and in their case are arguably reasonable, but if you don't know how and why they work, they are goi…

This is a mechanism vs policy argument.

Defaults count. Elsewhere I've said that I prefer to start with rigid guarantees and relax them. Default policy matters because in practice:

* The documentation isn't read.

* Even when it's read, the documentation may be incomplete.

* When it's read and complete, the crucial segment may be skimmed.

* When the documentation is complete and the crucial segment was read, it may have been misunderstood because of unclear writing.

* When the documentation is complete and the crucial segment was clearly written and read, it may be forgotten later on.

Then a new DBA or programmer arrives, and the whole thing starts all over again.

Safety mechanisms that require active effort above the baseline configuration do not work very well. Saying "there is a great mechanism" does not describe the actual properties of the actual system. The default policy is the policy that counts, because a single omission will reintroduce it.

Windows XP, buffer overflows, botched system deployments and so on all have a common property: they require positive effort by humans in order to rise above their baseline safety/security/reliability profile. There is no failsafe -- they only work by constant vigilance.

I don't see that as a good thing.