[DB-SIG] autocommit

Magnus Lycka magnus.lycka@tripnet.se
Sat, 20 Sep 1997 02:45:52 +0200

At 09:05 1997-09-19 -0400, Jim Fulton wrote concerning the
complications of the double scope of the program and the SQL

>This is one of the reasons that I find object-oriented databases to be
>*far* more useful than relational databases.  For example, an object
>oriented database underlies our apps, programmers have almost no
>database-related logic in their apps.  Programers should not have to
>think about loading or storing data.  To me, the eplicit query and
>update required by relational databases is roughly akin to the 
>explicit malloc and free required by C.

Interesting. Maybe I'm deviating a bit from the purpose of the
SIG now, but I think this is interesting.

With centralized applications run through terminals it didn't matter
so much if the rules where in the application or in the database,
but with client server systems and direct database connectivity from
excel or whatever, a lot of functionality except storage such as
security and consistency control had to be placed on the database.
This is a pain since SQL itself isn't enough and extensions such as
database procedures differ between databases and lead to a strange
division of where logic is placed and largely duplication of 

When we now are going back to centralizing business logic through
three tier solutions and www systems, we can somehow lift out some
of the requirements from the database again.

An SQL database and an OO language in combination means that we
have two incompatible and overlapping descriptions of the same
thing. Sigh. Obviously the OO (eg Python) description is much
more versitile, since it contains methods as well as data structures.

On the other hand, SQL has it's merits, for instance in the ability
to perform ad hoc searches in the data. You don't have to specify
how things relate to each other until you perform the search.

Does the OO alternatives provide these possibilities as well? I've
never used a proper OODBMS, but I got the feeling that the relations
between tables are fairly solid, like in the program code, and that
it might be difficult to for instance extract all sorts of statistics
that we didn't intend to provide when the system was originally designed.

If this flexibility is not at all needed, I guess little more than 
flattening the objects is needed (ok, a slight simplification ;-) but I 
would like to have the flexibility for searches etc I have today with 
Oracle etc.

It's my experience that delivered and running database systems always
change during time: Fields change, come and go. The field which was
previously free text is now validated agains another table and for
another field it's the other way around. The users come up with new
ideas all the time regarding what kind of statistics they want to be
able to extract etc. These changes have to be made in a running 
environment with a few GB of data used all the time by hundreds of 

If the structure of the database was much more rigid or complex than
SQL, this wouldn't work. One argument against OODBMS's I've heard is
just that it's tricky to use data in a different way that initially
intended. If that is a real restriction OODBMS's are in my opinion
worthless in most real life apps. (It also seems like RDBMS's still
are very much dominating.) 

On the other hand, changing an SQL database might well cause pains
since the SQL code relating to one table might have to be updated due
to a tiny change, and it might be spread out through the application. 
With an OODBMS where all operations in a class/table/relation went 
through class methods, this program change might be much more localized.

It would be interesting to hear what you think about these issues.


Magnus Lycka, Folktrov. 6C, 907 51 Umea, Sweden
+46(0)90 198 498, magnus.lycka@tripnet.se, www1.tripnet.se/~mly

DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org