yes, we (trailbender.net) use a lot of stored procedures to abstract a lot of geo-spatial stuff that we do in PostGIS. I find that it's more straightforward to provide a facade to app service developers from the db (particularly for more difficult services)... which is nicely handled by SQLAlchemy... they just call a function and it returns a value or vector of values.. Trying to map geometry columns to the ORM is difficult and large unnecessary, IMO. The stored procedure provides the most efficient plan/mechanism for doing this. There is a school of thought of that all operations should be handled in the ORM.. that all data should be accessed as in-memory 'objects' via (OQL or whatever). I guess that's nice and neat from a conceptual perspective.. but not very practical.. particularly when performance matters (which is like..um.. always). ORM's inevitably have to manage large graphs of objects in-memory.. which they are not really designed to do. Data manipulation in ORM's tend to deteriorate into O(n) list management... which become re-factored anyway (ask Twitter about their experiences with the crappy Rails ORM).
Rambiling a bit.. but my point is that the Pylons architecture (of which SQLAlchemy is a base compoment) allows a significant amount of flexibility to choose the most efficient deployment techniques for the specific situation. Stored Procedures support within the framework is just one example of its holistic design philosophy. On Wed, Aug 26, 2009 at 12:00 AM, Philip Jenvey <[email protected]>wrote: > > > On Aug 25, 2009, at 7:15 PM, Jamie wrote: > > > > > It seems that most people who adopt a MVC framework are in love with > > the ORM stuff. I'm just wondering if I'm the only one who insists on > > hand-writing my queries and sticking them in stored procedures? > > > > I guess it's because I come from a DBA/RDBMS development background > > and tend to make heavier use of the procedural logic available in a > > RDBMS, whereas most web developers use the DB purely as a bit bucket. > > I've tried to use a few ORMs, but have found them to be "too magical" > > and they get in the way of how I'm used to doing things. (In fact the > > primary reason I've adopted Pylons is because I can use it without an > > ORM). Is there any compelling reason why I should force myself to use > > SQLAlchemy? > > Stored procedures' popularity have mostly waned because they're not > portable across dbs > > ORMs are a different issue entirely. I can understand having issue > with ORMs for generating sub-standard schemas and queries. You > shouldn't have that problem with SQLAlchemy -- it avoids being too > magical and at heart its interests are aligned with yours as a DBA. > The marketing material on its web page claiming it's 'dba approved' > and 'unopinionated' is really true. > > It's not just an ORM, it also provides a SQL expression layer. You can > generate queries however you like them. You can also always fall back > to sending raw SQL through SQLAlchemy, and can even generate mapped > objects from their results. Also the core SQLAlchemy ORM follows the > data mapper pattern for better separation between the application's > object layer and the database layer. > > If you're not planning to write everything as stored procedures it'll > make your life as a DBA easier, not harder > > -- > Philip Jenvey > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
