Re: You're the master, I'm the apprentice

From: Pablo Sanchez <pablo_at_dev.null>
Date: 16 Sep 2002 11:07:56 -0500
Message-ID: <Xns928B6722097FFpingottpingottbah_at_192.168.1.1>


"Dave" <dave_at_dmcomm.com> wrote in
news:Cyfh9.43$2k1.38380640_at_news.incc.net:

> Tools on hand: MS SQLSVR 2000, ColdFusion
> Hands on hand: Only 2
> Skill: Novice
> Problem: see below
>
> I have customers (CUSTOMER table) and they can choose 1 or all 3
> of my services (phone, cabletv, internet).
> I'm not offering these services anymore, just want to store names,
> addresses, and what they got.
>
> It just seems like an awful waste of space if I have one CUSTOMER
> table with columns for the up to 3 services they have already
> ordered. There'd be a lot of
> empty fields if they only ordered one service!
>
> For only 3 products is it worth the space to have a PRODUCTS,
> ORDERS or even ORDER_LINE tables to converge all?
>
> Normalization points to this, but I don't foresee doing any
> complex manipulation with this DB... I mean this process is over,
> the services are ordered...there's a work-order #, but there's
> nothing to track, process is over.
>
> It was all done in person with pen and paper.

Hi Dave,

If you truly believe that this is going to be a dead application, sure, make it 'throw-away' and create a single, denormalized table. Use VARCHAR() with NULL on the columns that are sparsely populated. This way you won't eat space.

> Now my 3 services have subsets, if I were to implement a "true"
> DBMS, would I have to create tables for each product's subsets?
> Size, color, etc... I'm not going to implement this, but if, is
> the above question's answer in the affirmative?

I might do something like this:

[customer] ->[customer_product]<-[product]

The [customer_product] table would have 'attributes' such as size, color etc. You'll have to make a call in terms of how 'generic' you wish to build the [customer_product] table.

HTH!

-- 
Pablo Sanchez, High-Performance Database Engineering
http://www.hpdbe.com
Received on Mon Sep 16 2002 - 18:07:56 CEST

Original text of this message