Paul Boddie wrote: > ... I've come to realise that most object-relational mappers are > solving the wrong problems: they pretend that the database is somehow > the wrong representation whilst being a fast enough black box for > holding persistent data (although I doubt that many people push the > boundaries enough to see that it's not possible to ignore all details > of such a database whilst preserving performance), or they pretend > that languages like SQL (which can be cumbersome, admittedly) are > inconvenient for querying whilst replicating a less concise mechanism > for querying using client language mechanisms.
<bit-of-a-rant> Well at the risk of oversimplifying (!) I find there are two kinds of programmers using databases: those, like me, for whom the database is the application and who can happily envisage any number of interfaces, human and otherwise, to the data; and those, like 70% of the people I've ever interviewed for a job as a SQL developer, for whom the interface is the application and who simply throw things at whatever database they're presented with. The former will more likely tend to reach first for SQL to retrieve their data efficiently before passing it on to the front end for presentation or manipulation. The latter (and I've seen this far too often in interviews) will basically do "SELECT * FROM x WHERE y" to pull everything back into their VB.Net app where they feel more at home. Or, in the case of Python, reach for an ORM. I've recently used Elixir and found it very useful for a small-scale database with no more than a dozen tables, well-structured and easily understood. I'd certainly use it again for anything like that to save me writing what would amount to boilerplate SQL. But I'd hate to imagine it in the context of my day job: a messy, organic and sprawling SQL Server database with over 1,000 tables, let alone views, procedures and so on. </bit-of-a-rant> TJG -- http://mail.python.org/mailman/listinfo/python-list
