3 ms·
But that doesn't matter, you still can use tools to help compose the 90% of SQL that is quite boring Truth be told I think it is the "i write 100% of my SQL by
by zzzeek 7y ago
But that doesn't matter, you still can use tools to help compose the 90% of SQL that is quite boring
Truth be told I think it is the "i write 100% of my SQL by hand" crowd that is still quite junior in their SQL experience. How many times would they like to write a rote INSERT statement over and over against their data records before realizing an abstraction would save them lots of typing and redundancy?
Edit: also note that ORMs most certainly can be used with stored procedure architectures in theory. I'm not sure if such tools exist but if I had to use SPs, I'd be writing tools to both generate the SPs from a given set of models as well as to do the runtime work of marshaling my objects to and from these SPs from cursor.callproc() in the same way an ORM does it to plain SELECT / INSERT / UPDATE / DELETE statements from cursor.execute(). Additionally, systems like PostgreSQL's pluggable SP languages, which includes Python, might even allow SQLAlchemy models to work inside a stored procedure, something I've always wanted to try. Both concepts are things I'd gladly pursue if someone wanted to pay me a few years' salary.