3 ms·

MySQLs lack of views for a long time was just killer. I'm truly surprised MySQL has done as well as it has for as long as it has done. I thought that it's popul

MySQLs lack of views for a long time was just killer. I'm truly surprised MySQL has done as well as it has for as long as it has done. I thought that it's popularity would have tailed off when people realized just how much it was missing (I felt a little bit unwell when I found it didn't have views), but it seems that it just hit critical mass.

derefr 16y ago
I have a feeling that the basic "need" for ORMs was originally driven purely by the unwieldiness of querying a MySQL database. When everything is in the application layer, you have to write abstractions on top of it to keep it comprehensible. When you have triggers and views, on the other hand, you can just "ask the right questions" of the database, and get your information; the SQL becomes self-documenting, rather than a tangled mess.
- pvg 16y ago
  http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... Whatever their merits, ORM layers and the problems they try to address existed long before and quite independently of the particulars and limitations MySQL.
  - mmt 16y ago
    I've always felt that begs the question, by assuming that a mismatch is somehow fundamental, rather than an implementation artifact. Just as real RDBMSes don't strictly adhere to the formal math relational model, object-oriented languages vary in their, for lack of a better word, orientation. Looked at another way, what about a relational-object model instead? Making a useful one for MySQL doesn't seem as plausible, given its chronic feature absence.
- gaius 16y ago
  Just as the "need" for sharding is driven by MySQL's lack of a sensible way to do big joins.
drblast 16y ago
It goes to show you how important a few critical features (buzz, easy installation, performance) can be to early uptake, and it snowballs from there. From my perspective, there has been absolutely no reason to choose MySQL over Postgres if you want a DB for a long time now. If you just wanted a fast data store with replication and without the ACID features, you probably really wanted Berkeley DB over MySQL. The reason this is an interesting study is because MySQL has been so popular for so long. They did the right things at the right time to become popular. And the timing WAS perfect; an easy to use and install database in 1999 when before the .com bubble burst, when so many people (like me) were using a database for the first time and didn't know the first thing about RDBM's.

derefr 16y ago

I have a feeling that the basic "need" for ORMs was originally driven purely by the unwieldiness of querying a MySQL database. When everything is in the application layer, you have to write abstractions on top of it to keep it comprehensible. When you have triggers and views, on the other hand, you can just "ask the right questions" of the database, and get your information; the SQL becomes self-documenting, rather than a tangled mess.

pvg 16y ago
http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... Whatever their merits, ORM layers and the problems they try to address existed long before and quite independently of the particulars and limitations MySQL.
- mmt 16y ago
  I've always felt that begs the question, by assuming that a mismatch is somehow fundamental, rather than an implementation artifact. Just as real RDBMSes don't strictly adhere to the formal math relational model, object-oriented languages vary in their, for lack of a better word, orientation. Looked at another way, what about a relational-object model instead? Making a useful one for MySQL doesn't seem as plausible, given its chronic feature absence.
gaius 16y ago
Just as the "need" for sharding is driven by MySQL's lack of a sensible way to do big joins.

drblast 16y ago

It goes to show you how important a few critical features (buzz, easy installation, performance) can be to early uptake, and it snowballs from there. From my perspective, there has been absolutely no reason to choose MySQL over Postgres if you want a DB for a long time now. If you just wanted a fast data store with replication and without the ACID features, you probably really wanted Berkeley DB over MySQL. The reason this is an interesting study is because MySQL has been so popular for so long. They did the right things at the right time to become popular. And the timing WAS perfect; an easy to use and install database in 1999 when before the .com bubble burst, when so many people (like me) were using a database for the first time and didn't know the first thing about RDBM's.