3 ms·
I don't believe that there really are all of these developers around who lack knowledge of SQL. I learned SQL while I was learning to program. My very first (r
by JoelMcCracken 16y ago
I don't believe that there really are all of these developers around who lack knowledge of SQL.
I learned SQL while I was learning to program. My very first (real?) program was a php hit counter that wrote to a hits.txt on the server. My second one was a guestbook that used mysql. My third one was a basic hierarchical forum. I wasn't a wizard, I was just a kid reading a book, bored at the Pennsylvania Farm Show.
Thus, I have spent my fair share of time working with sql queries in php code. Guess what? The SQL queries weren't very hard at all.
However, SQL Queries had almost nothing to do with actual using SQL itself. 90% of the code written in such a project is guaranteed to be cruft code surrounding the sql queries. Special cases abound. The difference between "column = $val" and "column is null" is so painful that I just can't imagine going through that anymore.
And that's just the first example! What does "" mean if you save it in a db column? Should you save it as a null value, or as a string with zero characters?
I just don't care about this at all, and you'd have to be a damned fool to think that I would ever willingly go back to doing that bollocks.
I already have my in-memory data structure laid out. ORM lets me keep from worrying about it it again (at least not nearly to the detail I would with SQL). With an ORM, 90% of the database code that I used to have to deal with is simply a non issue.
- seldo 16y agoI think you are misunderstanding the article; it's not that object models for data are bad, it's that mapping them to a relational store is inefficient and pointless. The point against ORMs is not that they have inferior APIs -- in fact I say how bad SQL is. The point is that they wrap quite nice APIs around an inappropriate data store. If you have an object-like in-memory data structure, why not use an object store and have it in your data as well? The relational nature of your store is working against you. If your ORM exists to keep 90% of the database code hidden, why not dispense with the RDBMS entirely and lose that useless 90%?
- mistermann 16y agoMaybe because it makes that 90% legacy code useable?
- silentbicycle 16y agoNo personal offense intended, but there seem to be a lot of people who kinda-sorta understand SQL in that way, but run into performance issues because they don't understand important basics (indexing, for one), and are too quick to blame their problems on "SQL not scaling". When I hear people psyched about the whole NoSQL thing but actually quite ignorant about relational databases (like a guy who gave a presentation on CouchDB at a barcamp here last year), I understand why people sometimes call it the "NoMySQL" movement - a lot of the hype seems to come from people whose experience seems couched in PHP+MySQL tutorials, specifically.
- Confusion 16y agoI don't believe that there really are all of these developers around who lack knowledge of SQL. I'm not sure why you don't believe that, but as someone that has done development at a variety of companies: trust me, there are plenty of those. They may even be reasonable at PHP or Java, but they couldn't subquery their way out of a paper bag. At one place, the CTO, formerly main PHP/MySQL developer, didn't know what an index was. You can figure out the rest ;)
- JoelMcCracken 16y agoSorry; I'm not saying that all developers know SQL. I'm saying that the ones that we are all talking about know, or are competent enough to quickly know, SQL. To me, the people that you are talking about have no context in the discussion in the least. They would be the last to jump on the NoSQL bandwagon because they don't really care, for example. The universe of discourse only includes the devs who care, e.g. the people who are creating ORMs, using ORMs, using NoSQL, etc, not _all_ developers. I kinda assumed that was implied.