Re: table count limitation

Andrew,

As I was reading Marcin's reply to my message of earlier today I began to think of
how PGSQL has been extended. My thinking was purely relational, an "objectified"
approach would probably be worth considering.

andrew(at)ugh(dot)net(dot)au wrote:

> On Sun, 27 Aug 2000, Miles Thompson wrote:
>
> > Other columns could simply be labelled "descrip1", "descrip2", "descrip3", as
> > many as you need, for the different attributes of each item. So "descrip1" may
>
> Now someone once said to me "If you find your labeling your fields x1, x2,
> x3... then your design is wrong." His next step would be to ask for your
> ER diagram :-)

Yeah! I used those because they were general - attributes for outboard motors would
be quite different than those for antique glass or sports cars.

> Have you tried inheritance? i.e you will have a product, inheriting from
> that you will have computers, boats, cars etc. Perhaps from boats you
> could have sail boats, motor boats etc as you store different attributes.
>
> As postgresql is an OORBMS it should be able to handle it without any
> nasty squash into the relational model tricks.

Agreed, but won't you then have a mess of tables, different forms, different reports
to contend with? What's the difference between having this and a product type field?
I could be wrong, but let's say we take Marcin's earlier table description, and call
it item.

Then we subclass it to boats ...
boats = extends item

and then we subclass boats ...
sailboats = extends boats
motorboats = extends boats
runabouts= extends motorboats
trawlers = extends motorboats

I think we end up with a hell of a mess, and the parent class is 3 levels up for
trawlers and runabouts. I've not worked with object-relational or object-oriented
databases, so I could be missing something, and I'd be willing to be proven wrong.

We're also back to Marcin's original question - Is there a limit on the number of
tables? I don't know, but I'm very uncomfortable with a new set of tables created
for every variation in a product or item type.

> I've never used an OO database in production mind you...perhaps there is
> some catch I'm not aware of.

I'd love to hear from someone who has done one.

Regards - Miles Thompson