Re: Question on Structuring Product Attributes
Date: Sat, 15 Oct 2011 02:41:24 -0700 (PDT)
Message-ID: <6a0842a4-beb5-4bbd-875d-28bb7346c49b_at_z32g2000pra.googlegroups.com>
Roy Hann
On Oct 11, 6:55 pm, Roy Hann <specia..._at_processed.almost.meat> wrote:
>
> Surprisingly to me, Joe is advocating what I would have suggested. It
> is entirely respectable, though it may not be all that common.
> The common approach is to just cram everything into one table with lots
> of nullable attributes to hide the conflation of fact types, then leave
> the whole mess under the carpet so that the application code has to
> figure out the real business model at run-time, every time.
So that's where you have been spending your time. Now I understand the questions you ask.
> Explicit support for distributed key constraints in SQL would make the
> approach properly robust plus it would, in my opinion, have the
> psychological benefit of pointing the way and comforting us that we're
> doing it right.
Reading an appropriate book will provide both comfort and the method
of doing things correctly. A bit of genuine coding and experience
will provide knowledge about which methods are better than others.
SQL is 20 years past its use-by date, so no use waiting for them. If
a book is too long, try IDEF1X, it has a good, short synopsis. If
that is too long, try this:
____http://www.softwaregems.com.au/Documents/Documentary%20Examples/
IDEF1X%20Notation.pdf
They are not "distributed keys". They are ordinary Foreign Keys. The tables happen to be Subtypes.
If you find anything less than proper, robust, declarative (in the DDL sense, not the syntax), and high performance, in my (2) and (3) above, let me know. On second thought, don't. That will lead to me having to write essays on the resources and operation of the computer. There are perfectly book books on Amazon.com.
Regards
Derek
Received on Sat Oct 15 2011 - 11:41:24 CEST