3 ms·

Any attempt to throw away SQL is misguided. If you are going to do server side development, you must know SQL. Thinking in sets is hard work, but you must lea

by russell 18y ago

Any attempt to throw away SQL is misguided. If you are going to do server side development, you must know SQL. Thinking in sets is hard work, but you must learn it. For the most part fancy ORM's just get in the way. The solution is not less SQL; it's more SQL. Stored procedures are your friends. When I write a complex query, I develop and test it entirely in SQL, before I write a line of procedural code. It's way easier. The thing about query optimization is that the optimizer stops when it thinks going on will take longer to perfect it than executing what it has. If you have a query that takes too long look at the query plan. Break up the query into smaller queries and use temporary tables. Give it hints. Dates are often poorly handle in language libraries. Store them as UTC in the database and pound them into shape in code. Apologies for the counter rant.

davidmathers 18y ago
Any attempt to throw away SQL is misguided. Maybe not throw away, but why should we have only 1 relational language? Functional programmers can choose between scheme, ocaml and haskell. Why should we be stuck with what is in so many ways the COBOL of relational languages as our only option?
- russell 18y ago
  What I meant was that, as far as I have seen, the tools that try to replace SQL by some OO intermediary, give you poorer abstractions that limit what you can do. SQL seems clunky, but I think the core is quite well done considering when it comes from. OTOH a relational relational database doesn't fit all needs. They scale pretty well, but when you get to gigantic data sets, they don't do so well and things like map reduce do a better job. Or cases where you are streaming massive amounts of data and you need performance, not ACID transaction reliability. Actually, we are more in agreement than disagreement.
  - neilc 18y ago
    They scale pretty well, but when you get to gigantic data sets, they don't do so well and things like map reduce do a better job. I don't think the evidence supports that. See the recent MR vs. parallel DB comparison, for example: http://database.cs.brown.edu/sigmod09/ http://database.cs.brown.edu/sigmod09/ There isn't a good massively parallel open source SQL implementation right now, but that is just a matter of engineering -- SQL databases have been shown to scale to massive data volumes (e.g. Fox Interactive have ~200 TB of user data in Greenplum, which is a parallel DB based on Postgres).
silentbicycle 18y ago
Well, replacing SQL with a better declarative, relational language is an option. I happen to really like the relational paradigm, but the syntax etc. of SQL has plenty of historical cruft. (As a bonus, ditching MySQL would probably help shrug off a lot of inaccurate assumptions about real RBDMSs.)

by russell 18y ago

davidmathers 18y ago

Any attempt to throw away SQL is misguided. Maybe not throw away, but why should we have only 1 relational language? Functional programmers can choose between scheme, ocaml and haskell. Why should we be stuck with what is in so many ways the COBOL of relational languages as our only option?

russell 18y ago
What I meant was that, as far as I have seen, the tools that try to replace SQL by some OO intermediary, give you poorer abstractions that limit what you can do. SQL seems clunky, but I think the core is quite well done considering when it comes from. OTOH a relational relational database doesn't fit all needs. They scale pretty well, but when you get to gigantic data sets, they don't do so well and things like map reduce do a better job. Or cases where you are streaming massive amounts of data and you need performance, not ACID transaction reliability. Actually, we are more in agreement than disagreement.
- neilc 18y ago
  They scale pretty well, but when you get to gigantic data sets, they don't do so well and things like map reduce do a better job. I don't think the evidence supports that. See the recent MR vs. parallel DB comparison, for example: http://database.cs.brown.edu/sigmod09/ http://database.cs.brown.edu/sigmod09/ There isn't a good massively parallel open source SQL implementation right now, but that is just a matter of engineering -- SQL databases have been shown to scale to massive data volumes (e.g. Fox Interactive have ~200 TB of user data in Greenplum, which is a parallel DB based on Postgres).

silentbicycle 18y ago

Well, replacing SQL with a better declarative, relational language is an option. I happen to really like the relational paradigm, but the syntax etc. of SQL has plenty of historical cruft. (As a bonus, ditching MySQL would probably help shrug off a lot of inaccurate assumptions about real RBDMSs.)