Re: S.O.D.A. database Query API - call for comments

In comp.databases.theory Lee Fesperman <firstsql_at_ix.netcom.com> wrote:
> Storing a table row as an object messes up the query language.

I'd rather store an object as a table row.

A table row is just a table row. It's not useful for anything than making the database work. So I see no use of encapsulating a table row inside an object. That would certainly be messy. A table row should never be encapsulated at all, that make searching more difficult. The whole idea about encapsulation does not fit in a database context.

An object, at the other hand, is a construct that simulates the real world, and a construct that it's easy to deal with in a programming environment. Storing an object in tables is not a difficult task.

> How about storing objects
> as column values in table rows. Then you can keep a declarative query
> language and be able to call methods on columns.

Hm ... having one complete object as a single attribute in a table row? Must be a reference in that case? Or just a piece of binary data?

I'm not sure if that's a good idea. For one thing, the data within the object will be encapsulated, searching will be difficult. For the other thing, I think it might make sense to call methods on a table row. I.e. you have some geometrical data about a box in a table row, but not the volume. The volume can be returned through a method.

Creating, deleting and updating of table rows should also be done through methods; it might be needed to do some extra work.

I'm not quite sure, but I think I share your opinion that the query language ideally should be declarative. I think a lot of problems might be solved by using complex views. Particularly if it was possible to insert, update and delete rows in a view.

There is just one big catch, it's extremely difficult to make really good query optimizers. Try doing something really fancy with SQL, and the very most database servers will stall for ages before returning something. At my former workplace, I was even adviced that for a simple join over two tables, I should take out all data (90% unuseful data) from both tables and rather use perl to filter out the data I needed.

-- 
Tobias Brox - freelancer for hire!
Programming, system administration, etc
+47 98660706 / tobiasb_at_suptra.org