Hi Robert,
Inheritance normally are defined in the Object Orientated environment.
I however have a different perspective regarding when a database is
defined as OO.
One of the most common OO-databases that I am familiar with is
Intersystems Cache.
If for example we look at how PG create inheritance compared to Cache
(abstract wise):
PG:
CREATE TABLE Person
<Person details>;
CREATE TABLE Student INHERIT Person
<Student details>;
Cache:
CREATE TABLE Person
<Person details>;
CREATE TABLE Student INHERIT Person
<Student details>;
Nothing different in the design, however if we look at a query:
PG: SELECT * FROM Person
In this scenario PG will return a recordset that includes all records
from Person and Student as a UNION between Person and Student.
SELECT * FROM Student
PG will return a recordset that only include Students.
Now consider Cache:
SELECT * FROM Person
Cache will return a record set of everybody defined in the person datatable.
SELECT * FROM Student
The way Cache defines inheritance it will actually brings back a
recordset that is translated into:
SELECT * FROM Student, Person WHERE Person.person_id = Student.person_id
it therefore implies that a student cannot exist if it is not a person.
If we look at how OO is defined in programming languages, it is clear
that Cache follow a design nearer to programming language implementation.
So from my perspective, PG is not really a OO DB. We can however
through design make it to emulate OO, but it is not forced.
My 2cents worth.
Johan Nel
Pretoria, South Africa.
Robert Pepersack wrote:
Hi,
Thanks in advance for your help.
I have a lot of experience with object-oriented programming and
relational databases, but I'm new to PostgreSQL.
My agency has a contractor that created a PostgreSQL database that he
calls "object-oriented". I noticed that the contractor has more than
one value in a column separated by commas. In the relational world,
this obviously violates first normal form. When I asked about it, he
said that it's because PostgreSQL is an "object-oriented database". I'm
very skeptical.
Can someone tell me if this guy is right?
Thanks.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general