Re: Table design problem

"Mike Sherrill" <MSherrill_at_compuserve.com> wrote in message news:a738av4t8g53scubjc8n3rfkj3vm8qc4ke_at_4ax.com...
> Well, where I'm from, a customer is someone who has either bought or
> ordered a product from me. If they haven't bought or ordered from me,
> they're not a customer. Now, they might be a prospect. They might be
> a neighbor. They might be a vendor. But they're not a customer.
>
> A big part of database design is figuring out what you're talking
> about. Another big part is figuring out what you need to say about
> what you're talking about.
>
> The names of tables and columns are really, really important.

I agree that it is comforting to use names that have some mnemonic value, but there are no logical implications to them. If the data model ends up with a structure that makes it perverse or awkward or misleading to use a certain name, I agree we'd be wise to change it. But for the moment that's the name we use, and the data model is the only authoritative guide to its meaning, regardless of what name we might choose. I think you'd agree we'd be foolish to rely on anything else for meaning.

> I didn't recommend a separate party table and customer table. I
> suggested that you consider a) parties as a supertype, b) individuals
> as one subtype of parties, c) organizations as another subtype of
> parties.

OK, I agree you never said "create a customer table", but you did say "associate customers with the supertype parties". I guess I made the unwarranted assumption that that was somehow the essential idea you were proposing.

> You need several constraints to make sure your data is sane;
> I presume you've nailed those down?

Yeah, kindof. I couldn't see any way out of appending a discriminator to the primary key value and I was hoping I was wrong, but that's the only suggestion I got. It'll do the job.

> Your customers are just parties who have bought or ordered from
> you--most applications can simply use a query for that.

Well once again I am struggling to be sure I am not missing your point, because it seems to me that if you aren't advocating introducing a new table for customers, and you are advocating a "party" table with two subtypes, and I have to query to distinguish between parties who buy things and mere time-wasters, then you are just advising me to do exactly what I originally said I intended, with the inconsequential difference that you'd prefer me to use a different table name for my supertype. Or is there more to it?

Roy Received on Tue Apr 22 2003 - 10:53:02 CEST