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

Why Should You Use MySQL?

jeremymorgan.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Why Should You Use MySQL?

#21

Post by rosser »

AaronBBrown wrote: post #20
coderdude wrote: post #10

Earlier quoted context omitted.

One thing that bugs me is MySQL will truncate a value if the column can't hold it all and will only issue a warning (by default?). Although in most instances I've already done the foot work of checking a value's length, it would be nice to be able to throw an exception when it occurs. Of course that could be the choice of my framework and not MySQL's fault.

SET sql_mode = 'STRICT_ALL_TABLES'; http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html#... Yes, it's not default. Yes, it can be overridden. Yes, that bothers a lot of people.

Yes, that bothers a lot of people.

With good reason. This is your database we're talking about. If it's going to be sloppy with your data by default, it's the wrong tool.

Re: Why Should You Use MySQL?

#22

Post by taligent »

twerquie wrote: post #2

MySQL is to Postgres today as mSQL was to MySQL in 1998; more popular yet technologically inferior. In another 15 years, we will be having the same arguments about PostgreSQL and the thing that comes to replace it, whatever that may be. MySQL is in production and we have to live with it. The defences in the linked article are all valid. MySQL is a very sharp tool and can be used effectively. But its time has passed.…

Your analogy and your point is misguided. In another 15 years. MySQL will be legacy and PostgreSQL will be a footnote in history.

Because what you fail to understand is that people aren't switching from SQL to SQL they are switching to NoSQL and doing so en masse. Have you not seen the huge array of NoSQL options that weren't available 15 years ago e.g. MongoDB, CouchBase, Riak, Cassandra, HBase, Redis. And the upcoming trend is going to be in Graph databases e.g. Neo4J.

Re: Why Should You Use MySQL?

#23

Post by rosser »

taligent wrote: post #17
yummyfajitas wrote: post #3

1 reason to use MySQL rather than Postgres: 1) Your legacy shared hosting site might provide MySQL and not Postgres. There are also 9 reasons to choose one of {Postgres, MySQL} over {Oracle, SQL Server}. Here is 1 reason to use Postgres: data integrity. "00/00/0000 00:00:00.0000" is not a real date, but MySQL will helpfully insert it into your table if you try to insert NULL into a non-null datetime field. (One examp…

2) Clustering e.g. multi-master solution. 3) Decent monitoring. 4) Commercial support. And your argument about data integrity is valid but in the real world moot. Most developers are using an ORM these days which abstract problems like these away.

4) Commercial support.

EnterpriseDB, Command Prompt, 2nd Quadrant, and all the others listed under http://www.postgresql.org/support/professional_support/

Many of those companies have people on staff who are members of the PostgreSQL core committee, or at least have commit bits. Can MySQL say the same?

If your response is going to be "But that's not commercial support from 'PostgreSQL' itself", that's the nature of the community. It was a deliberate choice by the community to structure itself that way: PostgreSQL — the community, the brand, or whatever you want to call it — can't be sold. This is a good thing, and I don't think I need to waste much time explaining why...

Re: Why Should You Use MySQL?

#24

Post by derpmaster »

rosser wrote: post #23
taligent wrote: post #17

Earlier quoted context omitted.

2) Clustering e.g. multi-master solution. 3) Decent monitoring. 4) Commercial support. And your argument about data integrity is valid but in the real world moot. Most developers are using an ORM these days which abstract problems like these away.

4) Commercial support. EnterpriseDB, Command Prompt, 2nd Quadrant, and all the others listed under http://www.postgresql.org/support/professional_support/ Many of those companies have people on staff who are members of the PostgreSQL core committee, or at least have commit bits. Can MySQL say the same? If your response is going to be "But that's not commercial support from 'PostgreSQL' itself", that's the nature of t…

I am forced to use mysql for an experimental homomorphic encrypted db. Now that I know there's actual pro support for PostgreSQL that have commits I'm never going to use mysql ever again as I was just hung up on a few things while porting to Postgre. Great success I can't wait to nuke mysql from my system forever

Re: Why Should You Use MySQL?

#25

Post by freshhawk »

taligent wrote: post #22
twerquie wrote: post #2

MySQL is to Postgres today as mSQL was to MySQL in 1998; more popular yet technologically inferior. In another 15 years, we will be having the same arguments about PostgreSQL and the thing that comes to replace it, whatever that may be. MySQL is in production and we have to live with it. The defences in the linked article are all valid. MySQL is a very sharp tool and can be used effectively. But its time has passed.…

Your analogy and your point is misguided. In another 15 years. MySQL will be legacy and PostgreSQL will be a footnote in history. Because what you fail to understand is that people aren't switching from SQL to SQL they are switching to NoSQL and doing so en masse. Have you not seen the huge array of NoSQL options that weren't available 15 years ago e.g. MongoDB, CouchBase, Riak, Cassandra, HBase, Redis. And the upcom…

Bit of a filter bubble effect going on here.

Re: Why Should You Use MySQL?

#26

Post by vor_ »

taligent wrote: post #17
yummyfajitas wrote: post #3

1 reason to use MySQL rather than Postgres: 1) Your legacy shared hosting site might provide MySQL and not Postgres. There are also 9 reasons to choose one of {Postgres, MySQL} over {Oracle, SQL Server}. Here is 1 reason to use Postgres: data integrity. "00/00/0000 00:00:00.0000" is not a real date, but MySQL will helpfully insert it into your table if you try to insert NULL into a non-null datetime field. (One examp…

2) Clustering e.g. multi-master solution. 3) Decent monitoring. 4) Commercial support. And your argument about data integrity is valid but in the real world moot. Most developers are using an ORM these days which abstract problems like these away.

With all due respect, it's presumptuous of you to act as if you have a better grasp on the real world than other developers or that you have direct knowledge of what most developers use.

Re: Why Should You Use MySQL?

#27

Post by taligent »

berlinbrown wrote: post #6
Legion wrote: post #5

I was expecting a more compelling case.

A lot of people use it. It is the Java of databases. Ironically, Oracle also is connected to Java.

> It is the Java of databases.

That makes absolutely no sense what so ever. Java is the dominate enterprise development platform.

MySQL is most popular in non-enteprise environments.

Re: Why Should You Use MySQL?

#28

Post by AaronBBrown »

rosser wrote: post #21
AaronBBrown wrote: post #20

Earlier quoted context omitted.

SET sql_mode = 'STRICT_ALL_TABLES'; http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html#... Yes, it's not default. Yes, it can be overridden. Yes, that bothers a lot of people.

Yes, that bothers a lot of people. With good reason. This is your database we're talking about. If it's going to be sloppy with your data by default , it's the wrong tool.

I suppose that depends on your definition of "database." This argument is very close to the No True Scotsman fallacy. Nowhere in the definition of "database" does it say that it won't default to truncating your data when you try to stuff it into a field that is too small. MongoDB, Riak, VoltDB, PostgreSQL, and CouchBase are all "databases" and they all have varying levels of strictness.

"it's the wrong tool" is an opinion and it is unsupported by history. It many cases, it's exactly the right tool and users are given the power to control the level of strictness they they require. Want to allow GROUP BYs that don't include all non-aggregate columns? Sure, you can do that. Or not. Want MySQL to accept what you give it and throw warnings instead of errors? Yep, you can do that, too. Or not.

The defaults are bad. No one will defend that. They are also easy to change. A privilege level allowing/denying the ability to change the sql_mode would be a welcome addition, also. Yet, MySQL is a capable tool that does some things really well, something things not so well, and some things terribly. Just like every other product out there. It is a tool. It works well for many, but not all cases. Apparently, you find it inadequate for your particular needs. I get that. You shouldn't use it.

Re: Why Should You Use MySQL?

#29

Post by sadmysqluser »

rosser wrote: post #23
taligent wrote: post #17

Earlier quoted context omitted.

2) Clustering e.g. multi-master solution. 3) Decent monitoring. 4) Commercial support. And your argument about data integrity is valid but in the real world moot. Most developers are using an ORM these days which abstract problems like these away.

4) Commercial support. EnterpriseDB, Command Prompt, 2nd Quadrant, and all the others listed under http://www.postgresql.org/support/professional_support/ Many of those companies have people on staff who are members of the PostgreSQL core committee, or at least have commit bits. Can MySQL say the same? If your response is going to be "But that's not commercial support from 'PostgreSQL' itself", that's the nature of t…

Commercial support for MySQL is evolving in a similar way. Oracle, Percona, SkySQL and others offer it (emphasizing their particular value-added flavor).

Re: Why Should You Use MySQL?

#30

Post by rosser »

AaronBBrown wrote: post #28
rosser wrote: post #21

Earlier quoted context omitted.

Yes, that bothers a lot of people. With good reason. This is your database we're talking about. If it's going to be sloppy with your data by default , it's the wrong tool.

I suppose that depends on your definition of "database." This argument is very close to the No True Scotsman fallacy. Nowhere in the definition of "database" does it say that it won't default to truncating your data when you try to stuff it into a field that is too small. MongoDB, Riak, VoltDB, PostgreSQL, and CouchBase are all "databases" and they all have varying levels of strictness. "it's the wrong tool" is an op…

If no-one will defend that the defaults are bad defaults, then why are they the defaults?

As for the "No True Scotsman" notion, fair enough; point conceded. I just can't imagine anyone who actually, you know, cares about their data being happy about finding out — by virtue of the fact that the sloppy behaviors are the default — that they've lost data, or had it corrupted somehow, because of those defaults.

Yes, it's their responsibility, in choosing the tool, to make sure they're using it properly. But the folks making the tool should also have some degree of responsibility to their users not to fuck up their data. Maybe I'm just spoiled, having lived and worked in the PostgreSQL world as long as I have. There, breaking users' data is tolerated about as well as Linus tolerates kernels breaking userspace...

Post reply on HN