Re: The Zen nature of a Delphi database application

"marek jedlinski" <marekjed@xxxxxxxxxxxxxxxxx> wrote in message
news:p4hft29l6q8bbsnat23askq0ro69pq0ptb@xxxxxxxxxx
[...]
What about storing polymorphic objects in a DB? That's another
bit of a snag for me. What used to be a single collectin of
polymoprhically-accessed objects is now a number of different
tables, since each subclass needs its own set of fields.

Give the class a virtual method and override it in each class that
needs different behaviour. Basic OO (sorry Bjørge).

This is of course for storing. Retrieving might be a slightly
harder problem, what with probably needing to know all possible
descendent classes beforehand. Although registering classes isn't
particularly hard.

There are three ways to store polymorphic objects in a relational
database that I'm aware of. You can have a single table with
optional fields for all possible cases, or a different table for
every possible case, or extension tables for all child classes,
that have a foreign key as their primary key. Only the second
option is safe in that it's impossible to construct records for
which you don't have a class available. The third corresponds
very nicely to classless prototype-based (ad-hoc, 'instant')
polymorphism.

If anybody knows more patterns, I'd be happy to know.

Groetjes,
Maarten Wiltink


.