Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL - Do Not Pass This Way Again

grimoire.ca

Post reply on HN
Print view View original

151–160 of 164 posts

Re: MySQL - Do Not Pass This Way Again

#151

Post by robertfw »

stef25 wrote: post #94
willlll wrote: post #56

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.

I'll second pgadmin. I finally woke up to the fact that I should start using Postgres a few months ago, and pgadmin made my initial foray into postgres very straight forward

Re: MySQL - Do Not Pass This Way Again

#152

Post by simonw »

simonw wrote: post #103
toast0 wrote: post #67

Earlier quoted context omitted.

try to never change the database structure works pretty well. For all other cases, the easiest solution requires that you have a good redundancy system in place, and some extra planning. But basically run alter table without replication on your out of rotation slaves and masters, and then swap. Depending on your backup situation, you could probably just run the alter table on your backup systems and then restore from…

This has been one of the biggest changes I've noticed since our team switched from MySQL to PostgreSQL: our database design is now much, much better and we make changes to it much more often. I has grown used to compromising on database quality to avoid having to make frequent changes to large tables: implementing a new feature as a join table for example rather than adding the columns it needs to a core, multi milli…

That should be nullable, not billable.

Re: MySQL - Do Not Pass This Way Again

#153

Post by jmix »

nnnnni wrote: post #72

"I'm going to rant against MySQL, but I'm not going to suggest a better alternative."

In what entitled universe do you live in where a guy who carefully and patiently points out problems is also obligated to solve every single one of them?

Also, do you really need someone to spell out the alternatives to MySQL? There are too many to list.

Re: MySQL - Do Not Pass This Way Again

#154

Post by jeffdavis »

twerquie wrote: post #149
pippy wrote: post #82

I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great fe…

> PostgreSQL is pedantic with data insertion Better to deal with the exceptions up-front, than to discover months down the line that your database has been silently chopping long strings, silently casting types and coercing values into useless junk.

"Better to deal with the exceptions up-front"

That may be, but when an application developer is developing, they primarily need to get data into the database. That may be right or wrong[1], but it has a big impact on the adoption of particular database systems or practices.

And it's somewhat irrelevant to this discussion, because there are many ways you can feed the data you want into postgres (like declaring columns BYTEA, TEXT, or HSTORE), no matter how "bad" it is. I would argue that it's much easier to deal with "bad" data in postgres than mysql because you have so much flexibility (e.g. write a function inside of postgres in PL/python to get some meaning out of the ill-specified data; or write some triggers to do post-processing).

[1] I personally think that a misalignment of incentives is responsible for the widespread focus on the ease of writing into a database without considering the utility of the data once it's in there.

Re: MySQL - Do Not Pass This Way Again

#155

Post by jeffdavis »

sadmysqluser wrote: post #89
pippy wrote: post #82

I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great fe…

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 of "bad data" that needs to be cleaned up later. Maybe by doing so, you realize that the data isn't "bad", your schema just needs to be updated to reflect new interesting cases.

* You can pull data in from remote sources with foreign data wrappers, which might be necessary to clean the data up properly (e.g. one extra join against the company LDAP directory using the email might be able to canonicalize those employee names).

* You can catch errors using subtransactions and have a different processing path for data that doesn't fit in the schema.

Maybe some of these features exist in MySQL (I haven't been a real user since around 2003, aside from a bit of administration). But in postgres, these features all work together seamlessly along with all of the other features in postgres to make it all work nicely and without a pile of caveats. And that matters a lot when trying to wrangle strange data.

Re: MySQL - Do Not Pass This Way Again

#156

Post by nnnnni »

jmix wrote: post #153
nnnnni wrote: post #72

"I'm going to rant against MySQL, but I'm not going to suggest a better alternative."

In what entitled universe do you live in where a guy who carefully and patiently points out problems is also obligated to solve every single one of them? Also, do you really need someone to spell out the alternatives to MySQL? There are too many to list.

The article would have been much more credible if it would have said something like "try postgresql instead". It has nothing to do with entitlements.

Re: MySQL - Do Not Pass This Way Again

#157

Post by jmix »

nnnnni wrote: post #156
jmix wrote: post #153

Earlier quoted context omitted.

In what entitled universe do you live in where a guy who carefully and patiently points out problems is also obligated to solve every single one of them? Also, do you really need someone to spell out the alternatives to MySQL? There are too many to list.

The article would have been much more credible if it would have said something like "try postgresql instead". It has nothing to do with entitlements.

He does not need to be able to point to an extant, better alternative for his criticisms to be "credible."

BTW, I can't believe you're implying that his post is not credible. The practical outcome of your demand for a solution is to shut down legitimate criticism.

Re: MySQL - Do Not Pass This Way Again

#158

Post by ldh »

josephlord wrote: post #43
viraptor wrote: post #26

Earlier quoted context omitted.

I understand that and don't have issue with what he most likely meant - only what he wrote. In short - MySQL does not always comply with the SQL standard. That's unfortunate / silly / annoying / inconsistent. I completely agree. But I don't agree with "Foreign keys are ignored if you spell them certain, common, ways". This is not very specific. Common to what situation? People being used to it in another project? It'…

If it doesn't implement part of the SQL spec that is a shame but why if there is part of the statement that isn't understood or processed there is no excuse for not raising an error. That is unacceptable. Documenting it just isn't enough.

I did some brief searching, but didn't come up with anything. Certainly for such a problematic case there is at least a bug report filed requesting that an error is raised?

Re: MySQL - Do Not Pass This Way Again

#159

Post by pippy »

jeffdavis wrote: post #144
pippy wrote: post #82

I've been hearing bad things about MySQL, so I've been avoiding it as of late. So far my experience has been subpar. PostgreSQL is pedantic with data insertion, almost to a fault. This costs me development time. (Also I have no idea what my users will do, and I'd rather have faulty data inserted than none at all. If it's for a client asking about a product, this could cost money). Yet purists claim this is a great fe…

"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.

Re: MySQL - Do Not Pass This Way Again

#160

Post by jacques_chester »

LaGrange wrote: post #139
jacques_chester wrote: post #115

Earlier quoted context omitted.

Right, but we're not talking here about scale. We're talking about ... trustworthiness, I suppose. Dependability. 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 fin…

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.
Post reply on HN