Re: *Proper* solution for 1..* relationship?

Kevin Grittner-5 wrote
>  We never wanted a header without detail, but we never
> wanted a detail row with a zero money amount, *and the sum of the
> detail rows for a transaction had to total zero*. 

Even in this scenario I'd argue that the option to generate an entry without
any money detail would have value.  Imagine an accounting system that posts
service invoices.  Invoice numbers are supposed to be issued and consumed
sequentially and sometimes an invoice must be voided.  There is no
meaningful amount that you would want to post but having the accounting
system process that invoice anyway and generate an empty entry with "Voided
in Service" as a header comment would aid in auditing.

By allowing for zero-children you provide a richer model for the developer
to use.  It is kind of like "null".  The reason it exists (ignoring its
flaws here) is because complete knowledge or even applicability is not
possible - sometime the lack of data has meaning (or, IOW, reality is
manifested in the lack of the normal/usual).  Instead of artificially
creating because nothing is not allowed the model (and users of it) should
recognize that they need to understand and deal with absence just as much as
they need to deal with presence.  Lacking that either the model will be
unusable for those "absence" situations - thus limiting its ability to
reflect reality - or (worse) people will abuse the model to make their data
fit.

In the example above not tracking voids in accounting is not a great loss
but it could be useful functionality that the system could offer if the
model did not force 1..* cardinality.  If someone really wanted to track
voids in accounting they would have to program a journal entry to post
non-zero amounts to either memo accounts or a washing entry to the same
account.  While that is feasible (and possibly desirable now that I think of
it) it still seems messy at first glance.

Sure, you would need to design the query interfaces to deal with "empty"
documents but that too is a worthwhile exercise.  In reality I would allow
only certain kinds of documents to be posted "empty" (like invoices) and
then have a special interface so that users can account for and manage those
empty entries in a semantically meaningful way.

Alas, I digress.

David J.






--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Proper-solution-for-1-relationship-tp5753384p5754134.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.