Hi, Ann, All!

> On the other hand, I would like to have temporary tables that
> use a subquery definition to be created to match the current
> results of the subquery and to have their data loaded on reference.
> Creating a new table instance - which is what a temporary
> table is, essentially - using data that was current when the
> table was defined seems ill-considered. Not to mention messy
> as hell, regardless of the implementation chosen.
>
> I will read the new standard closely and try to understand
> the intention of the committee...

I think most existing implementations go somewhat wrong when are trying
to incorporate some of the OO features into relational model without
considering the whole picture.

I have a vision how to implement inheritance, polymorphism, abstraction
and encapsulation principles while staying completely within relational
model.

Here are the following ideas:

1) table == object
2) object inheritance. If table inherits from another table records of
child should be visible in all ancestors
3) tables may have constructor and methods declared. Methods are called
with "record" ("this") reference and are all virtual.
4) table may contain details (tables==objects by themselves)

Example:

create table document (
id integer not null primary key,
detail doc_lines (
desc varchar(100),
amount numeric(10, 2)
)
)

When you do

select * from document.doc_lines

you should be getting all detail lines for all documents and also PK of
parents for all detail lines.
But when you work with this.doc_lines in methods of document you're
getting only records for this document instance.
When visible from outside detail simply contains all PK for all parent
tables.

5) all fields are actually properties (in J2EE and Delphi sense). I.e.
have visibility, optional reader and writer methods. When there is no
reader method engine manages the storage for field.
6) Table methods may be implemented using Java and PSQL interchangeably
7) tables/objects should form hierarchical package namespace

This way manipulating objects when implementing business logic becomes a
breeze. At the same time SQL access is fully retained.
Various databases implement portions of this approach, but I'm not aware
of anybody who implements this fully.

I was thinking of OORM approach for long time already, but never got to
actually implementing it.

> Ann

Nickolay