Diwaker Gupta wrote: > I reached this from Planet Python: > Another word on the Relational Model and Python > <http://betur.net/blog/?p=6> > > Very nicely written, and sums up my occasional confusion when working > with SQLObject. IIUC, SQLObject tries to be a pure ORM, and might not > always fit well with the relational model. > > I really wanted to know how people thought about it -- especially Ian > and other SQLObject developers. This mail probably belongs on their > mailing list, I'm just being lazy. I'm happy to repost there if needed > :)
I think he implicitly over-values the relational models. In practice 90%+ of tables are not designed for relational use, but are designed as classes and instances (with or without an ORM). I would posit that every table with a primary key is really about objects, not a relation in the relational algebra sense. When a row has a good primary key, it has an identity, and identity means that it has an existance beyond a single query, and it is not just the collection of its attributes. You can refer to it, you can pass that identifier around, and you know something about the values and types that it can contain. Relational thinking can be great for reading the database, but for writing to the database it is not very useful. While I suppose it is possible to use writable views, and even writable ad hoc views (aka selects), it's hard in practice to understand quite what that means. SQL updates and inserts are rather crude, as they pay no particular attention to the primary key and instead optimize set operations that are not often needed. As a result, people generally throw away relational thinking as soon as they start updating the database. SQLObject tries not to get in the way of reporting from the database, though it only provides tangential help and as a result it's not obvious how you use it. But people are figuring it out; this article might help anyone currently wondering about it: http://groovie.org/articles/2005/11/01/how-to-use-database-agnostic-sql-in-sqlobject SQLObject's relational support is not as set-oriented as SQL, and so as a result you sometimes do things in, say, Python for loops where you could do them in raw SQL without that. But those aren't fundamental issues with SQLObject's model, they are just the limits of its features. And, for instance, I added an improvement on the new joins in SQLObject which make the relationships a little easier to manage: http://pythonpaste.org/archives/thread/20051126.214959.ce7af58c.en.html -- certainly other features (like selecting multiple instances at once) would be possible. Some underdocumented features (like .select().filter()) also provide some help for relational thinking. Also, personally, I like to hang methods off my SQLObject classes. Methods work more nicely with classes and instances. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
