4 ms·

I love this document. This stuff is my porn. That said, I'm having quite a hard time grappling with section 4. First, what is the 'users' keyword all about i

I love this document. This stuff is my porn. That said, I'm having quite a hard time grappling with section 4. First, what is the 'users' keyword all about in the "bad" area? Second, why is ORM the "bad" approach, and manual construction of SQL strings the "good" one? It seems to me that the abstraction and centralization of query language is paramount (examples: to afford oneself an easy one-day migration to GQL/BigTable, or to a document-oriented database like MongoDB or the upcoming Couchbase).

Legion 16y ago
Just like how he reached for PyUnit for "readability counts", I definitely think of ORMs over raw SQL when it comes to "readability counts". Especially when you're actually working with data, not just the table creation step.
- endtime 16y ago
  Agreed completely. The difference between a good ORM and raw SQL is like the difference between, well, Python and assembly, IMO. Perhaps the difference is a little less extreme, but it's similar in spirit.
  - coolgeek 16y ago
    er, as someone who did much database access in assembler, I'm going to have to disagree with your analogy. You could argue "between Python and C"... but most certainly NOT assembler
    - endtime 16y ago
      Wow, I'm sorry you had to do that, haha. Python and C is surely a more reasonable comparison in terms of actual ease of use; I was thinking in terms of "raw instructions" versus "high level abstraction".
- mcginleyr1 16y ago
  The pretty examples aren't in order. In this case the doctests are the "pretty".
rhoeft 16y ago
I think maybe the ORM is being put forth as the good approach. In the 'simple is better than complex' section using the ORM was the 'complex' solution and using json was the 'simple' solution. In 'complex is better than complicated' the ORM is still the 'complex' solution, but that wins over the 'complicated' manual SQL solution.

Legion 16y ago

Just like how he reached for PyUnit for "readability counts", I definitely think of ORMs over raw SQL when it comes to "readability counts". Especially when you're actually working with data, not just the table creation step.

endtime 16y ago
Agreed completely. The difference between a good ORM and raw SQL is like the difference between, well, Python and assembly, IMO. Perhaps the difference is a little less extreme, but it's similar in spirit.
- coolgeek 16y ago
  er, as someone who did much database access in assembler, I'm going to have to disagree with your analogy. You could argue "between Python and C"... but most certainly NOT assembler
  - endtime 16y ago
    Wow, I'm sorry you had to do that, haha. Python and C is surely a more reasonable comparison in terms of actual ease of use; I was thinking in terms of "raw instructions" versus "high level abstraction".
mcginleyr1 16y ago
The pretty examples aren't in order. In this case the doctests are the "pretty".

rhoeft 16y ago

I think maybe the ORM is being put forth as the good approach. In the 'simple is better than complex' section using the ORM was the 'complex' solution and using json was the 'simple' solution. In 'complex is better than complicated' the ORM is still the 'complex' solution, but that wins over the 'complicated' manual SQL solution.