Ian Bicking: the old part of his blog

Re: ROM vs. ORM

Ian, I'm an amature SQLObject user and I generally agree with what you're saying, but I would add that in the case of subclasses, it would be nice if the supeclass could find subclass instances. Say, for instance, I have this kind of structure:

class Server(SQLObject):
...
class NameServer(Server):
...
class WebServer(Server):
...
class FileServer(Server):
...

Although the relational way to do this may be to structure one server table with server-type as a foreign key, if you're overloading your SQLObjects with methods appropriate for various kinds of servers, that kind of structure can be inconvenient:

class FileServer(Server):
def storeFile(...):
...

The way SQLObject creates tables for this makes sense, it's a poor relational model and if I want a way to grab all Server objects based on some criteria, it's troublesome. Of course, you can break up your model into smaller subclasses and tables, but in doing so I think you tend to lose what makes SQLObject so great, its simplicity and the resultingly simple models.

Having said all that, I'm not sure what the solution is or whether I think subtables are a good idea. It's been a while since I tinkered with PostgreSQL's Object-Relational notions, but I remember them being quite limited. Is there a way you could add some methods to superclasses for gathering subclass objects?

-Ken

Comment on ROM vs. ORM
by Ken Kinder

Comments:

A polymorphic join would be useful, certainly. This way a common server table could indicate the ID and table name that contains other information (i.e., DNS, web, or file information). There's also other ways to handle this relationally. Some of those techniques will require enhancements to SQLObject (though many of them are quite reasonable to implement in an ad hoc manner).

# Ian Bicking