Is there a way to create a template table, somewhat akin to an OO class?

Question

Hi everyone,
Here is my novice question of the day.
Say I would like to create a table which will describe the attributes of a set of tables. Each table in the set will have exactly the same field names, datatypes, etc..., but each table will represent a completely distinct data set. Is there a way to designate a table as a 'template' and then create tables which are instances of the table?
I know I could do something inelegant like TableA_Version1, TableA_Version2. But that just seems very clunky for the 21st century. I also do not wish to inter-mingle the data from TableA_Version1 and TableA_Version2 by putting a field in TableA called version.
Say, for example, my database contains information on different financial models. TableA would be the template or parent describing the characteristics which all of the models have. But each model would need to have its own 'version' of TableA.
Time may also logically separate the tables into different 'snapshots'. Again, TableA_DateStamp1, TableA_DateStamp2, seems unwieldy. What would be your suggestions here?
Thank you again for helping me with my beginner questions! I very much appreciate your time!
Holly (I was set up with the wrong name... Oracle is fixing that...I hope!)

Answer 1

The object stuff was pretty poor in Oracle8/8i. It's gotten a lot better in 9i but it still isn't as rich as (say) Java or Python.
OO vs relational is the type of topic that starts holy wars. How one feels about it is often a matter of where one started out from. What I will say is this: relational data modelling has a firm logical basis in mathematics, particularly set theory. Everything in an RDBMS is mathematically provable. OO has no similar mathematical underpinning.
I think OO has many advantages as a tool for building front-end applications but I wouldn't really want to trust my data to it.
Where does that leave Oracle's object implementation? Well, PL/SQL objects can be quite useful for building complex user-defined datatypes. It is at least a partial way of implementing the DOMAIN functionality that RDBMS ought to have and Oracle lacks. The problem is that it is difficult to normalise an object-based data structure, so they tend to have lots of duplicate data, with all the maintenance issues that follow.
Let's take a concrete example from the Oracle documents:
http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96624/13_elems32.htm#35076
<QUOTE>
The following example shows that you can nest object types:
CREATE TYPE Address AS OBJECT (
   street_address VARCHAR2(35),
   city           VARCHAR2(15),
   state          CHAR(2),
   zip_code       INTEGER
CREATE TYPE Person AS OBJECT (
   first_name   VARCHAR2(15),
   last_name    VARCHAR2(15),
   birthday     DATE,
   home_address Address,  -- nested object type
   phone_number VARCHAR2(15),
   ss_number    INTEGER,
);</QUOTE>
Now what happens if you have two instances of PERSON living at the same home_address? You have two instances of ADDRESS. If you get the zip code wrong you have to change it twice. If they both move house (they're married) then you have to give them both a new ADDRESS. Furthermore, because you have two instances of ADDRESS you have no way of telling that these two people live at the same address, except by scanning all the instances of ADDRESS in all the instances of PERSON.
The relational implementation is a lot simpler and cleaner. Two records in the PERSONS table each with a foreign key to a single record in the ADDRESSES table. It doesn't always happen, of course, but in this instance the relational implementation maps much more closely to the real world than the O-O implementation (two people, one house) . If you get the zip code wrong you only have to alter the ADDRESSES record, you don't touch the PERSONS table. If they move you create a new ADDRESES record and change the foreign key in PERSONS. Finding multiple occupancies is as easy as
SELECT add_id, count(person_id)
FROM   persons
GROUP BY add_id
HAVING count(person_id) > 1What could be simpler?
But then I would say that, I started out from the relational world. People from the O-O world look at things differently.
Cheers, APC