6 ms·
The main point that one should know SQL as much as possible before using ORMs, I agree with fully. The point that applications should be written by quick-proto
by zzzeek 14y ago
The main point that one should know SQL as much as possible before using ORMs, I agree with fully. The point that applications should be written by quick-prototyping with an ORM, then replacing the ORM entirely with raw SQL, I could not disagree with more. Since he is using my own ORM (SQLAlchemy) as his example, I'd like to point out (as many of you know I always do) that SQLAlchemy's entire approach is one of exposing the relational model at all times. There is virtually no need to drop out of using the Query and/or select() constructs into raw SQL strings, as these constructs can represent SQL fully and more or less directly, not really any different in concept than when the relational database itself parses an incoming SQL string into a tokenized parse tree internally. The results returned are tuples. If your tuples happen to line up with the attributes in your object model, then you can tell it to get objects back. There is no sharp red line between "I'm using an ORM!" vs. "I'm using SQL!". With a mature tool like SQLAlchemy you're using both, and the tool is there to automate your work with SQL, not to replace it.
So of course, learn SQL as fully as possible. But I recommend using an ORM that allows you to make full use of your SQL knowledge at all times.
- aidos 14y agoIndeed. I do worry about the level of SQL knowledge that developers have in general these days. Without understanding it - and the relational model (which I'm a big fan of) - it's impossible to optimise the way you use the ORM. OT but thanks for SQLAlchemy. It's the model ORM in my opinion. It's the only one I've ever used that feels like it respects SQL. When I started working with Python fulltime I spent days reading through the SQLAlchemy source - I learnt a lot from that.
- moron4hire 14y agoThis is very important. Any time you build a bike with training wheels, you need to build in a way to take the training wheels off. Otherwise, at some point the solution is to not make faster training wheels, but discard the bike entirely.
- derleth 14y agoIs C training wheels on assembly?
- coldtea 14y agoNo. But an ORM is training wheels on SQL.
- moron4hire 14y agoRight, and (most) C compilers let you fall back on assembly if you absolutely must. So my point still holds, even if you do something silly like employ hyperbole on it.
- tjr 14y agoIf you've already learned SQL and are comfortable using it directly, do you think there is any reason that it'd be wrong to continue doing so?
- zzzeek 14y agoit's really not as much about the querying (though there is a lot of time-saving automation to be had there) as it is about integrating the data in your object model with the tuples being shuttled to/from the database. Like, at what point do you get sick of writing redundant "INSERT INTO <table>" over and over again? Are there really people who still don't see the time-wasting, code-cluttering repetition in that?
- silverbax88 14y agoI'm still amazed that there are developers who would rather spend more time maintaining/debugging/optimizing ORM code in a mature app that just learning a simple INSERT statement.
- d23 14y agoBecause in my experience, the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?), and the "optimizing" step hasn't been an issue for the traffic our sites get.
- papsosouid 14y ago> the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?) Nobody can agree on the point of ORMs, which is a large part of the reason why there's so much debate over whether to use them and how. I must say, if their point is to eliminate maintenance and debugging, then they are failing miserably at it.
- untog 14y agowho would rather spend more time maintaining/debugging/optimizing ORM code But that's kind of the point- with a decent ORM library there isn't really much work to do. model = MyModel.load(id) Add a new field to your model? It'll handle it. It might even modify the table for you. With raw SQL you'd have to go and edit your UPDATE and INSERT statements each time. Seems like a lot more maintenance/potential debugging to me.
- camus 14y ago> then replacing the ORM entirely with raw SQL, anyway it is usually never the case. Why would you build a complex app only to tear it appart with going back to raw SQL ? i'm not talking about SQLAlchemy but often the main problem with ORM is performance. Especially when a orm has its own query language on top of the SQL language ( Like Hibernate or Doctrine ). A good ORM imho is what you described , something very light but still usefull enough so one doesnt have to do data transformation from rows to objects. How does SQLAchemy fetch related objects ? is it is lazy ? or does it fetch everything when doing a join query for instance. Anyway thank you for your great work with SQLAlchemy.
- jfb 14y agoI have no interest in the 'O' or 'M' in an ORM, but I am very interested in a language better than SQL for interacting with SQL-based pseudo-relational datastores. I've found SQLAlchemy to be a pretty good tool in this respect.
- deleted 14y ago[deleted]