Re: updatable views

On Fri, 2005-01-28 at 19:38 +0100, SainTiss wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Certainly...
> 
> Try
> http://citeseer.ist.psu.edu/rd/31714464,229922,1,0.25,Download/http://citeseer.ist.psu.edu/cache/papers/cs/1421/ftp:zSzzSzftp.fmi.uni-konstanz.dezSzpubzSzdbiszSzPublicationszSzSLT:DOOD91.pdf/scholl91updatable.pdf

Dry stuff. Where to start?

First of all, it is a bit late when I am typing this and English is not
my first language. That alone can cause communication problems over
e-mail, and when you add my genetic defect of having diplomatic skills
that can be compared to an elephant in a porcelain shop, things can get
really nasty ;-).

In short: this is my personal opinion; I do not want to stand on
anyone's toes, and I'm sorry if I do.

Now to the article: "(...) any query (...)". Ah, that's where it goes
wrong, right in the introduction. Why would we need a query? A query is
_an_ implementation for getting data out of a database, not _the only_
one. I for one do not like queries in a language that is different from
the language I am writing in at that moment, if only for the fact that
the compiler will not correct my ever so often occuring typing errors in
queries. I absolutely despise two programming languages in one source
file.

Now for the reasons for such views:
1) Size of the schema. I fail to see the reason why a schema need to be
small to be manageable. Any OO application can have a zillion classes;
as long as you keep inheritance logical (and with java: package
structure logical) I see no reason to further split this up.

(Getting fed up with my arrogant tone yet? ;-)

2) Authorization. Why not simply make some method calls unavailable? Why
use views? Why not have the database throw an exception?

3) Integration. Why not use value objects, delegates or whatever? There
are perfect working patterns that every developer should know, why add
another concept?

4) Upward compatibility. Again, delegation/value pattern (Ozone uses yet
another 'transparent' solution).

I fail to see any of these 4 points as a good reason. Therefor I fail to
see the reason for views in an oodbms.

The article continues to use set-oriented algebra as if it were the only
way. The talk about 'insert', 'delete' and 'update' further gives the
impression that the writer thinks in a relational query structure. Ozone
is not at all a relational database; the main thing it has in common
with rdbms-es is that they both store data, and it pretty much ends
there.


Now what I think of Ozone: Ozone is a great way of making sure that
objects and references to other objects are persisted from one instance
of a JVM to another one starting up after the original JVM. The nicest
thing about Ozone is that it can be almost invisible; it does not get in
the way. You do not have to think that you use a database at all. No
need to 'store objects', 'update objects' or whatever, you simply
program in Java as you would normally do (with a few caveats of course),
and your data is simply there. There is even a bloody garbage collector!

There are no queries in Ozone, simply because there are no queries in
Java. Period. In Java, you get from one object to another by following a
reference. In Ozone it is exactly the same. Ozone mimics the way Java
works; it does not introduce alien concepts as queries, relations,
views, etc.


Now, back to your original question (if you could bare to read this
far ;-): does Ozone support views. No, it does not. Question back to
you: why should Ozone support views? More broadly: why should Java
support views?

Cheers,
Leo




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl