Re: Need advice w/ table design
From: Jochen Daum (jochen.daum_at_cabletalk.co.nz)
Date: 06/08/04
- Next message: Josh White: "Re: triggers - INSERTED table"
- Previous message: Jochen Daum: "Re: performance on SET TRANSACTION ISOLATION LEVEL"
- In reply to: Adam Machanic: "Re: Need advice w/ table design"
- Next in thread: Sam: "Re: Need advice w/ table design"
- Reply: Sam: "Re: Need advice w/ table design"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 08 Jun 2004 14:17:50 +1200
Hi Adam,
On Mon, 7 Jun 2004 21:04:58 -0400, "Adam Machanic"
<amachanic@hotmail._removetoemail_.com> wrote:
>Jochen,
>
>In a relational database, each table should conceptually represent one type
>of entity. Each row of each table is an instance of that entity, in the
>form of a predicate. So for a table representing computers, such as the one
>I posted:
>
>Computers
> IP
> Name
> Processor
> RAM
> VideoCard
> HardDrive
>
>... we could "read" a hypothetical row, for instance, as "Computer at IP
>192.168.2.2 is called ABC, has a Pentium 3 500 processor, 512 megs of RAM,
>an NVIDIA GeForce3 videocard, and a 40 gig Maxtor hard drive".
>
>Furthermore, each column is a specific attribute type, which implicitly
>constrains the data (in addition to other types of constraints) -- so in the
>processor column, you know you always have information about processors.
>
>In the schema you propose, the database cannot logically enforce attribute
>type or even datatype, reliably (although you could, I suppose, write
>complex CHECK constraints that take every possible attribute name into
>account). In addition, your application code will require logic for every
>attribute so that it knows what column to pull the data from.
>
>I don't expect any performance enhancement from this type of setup vs. a
>properly normalized schema, and I've already pointed out the data integrity
>issues. What benefits do you see?
I normally argue your way a well.
I have just written a synchronisation application for my company where
the client (top level) wants an automatic synchronisation, but the
actual people are not cooperative. Additionally they will also change
it now and then without telling us. I think in this case you have to
go for something more flexible.
I surely didn't mean to always use only two tables. Another example
would be an web shop system for a shop that sells computers and
clothing. I don't think creating 5 tables for the computer section and
3 for the clothing section is always appropriate. Instead you might
want to have items (with price, stock etc) and attributes of them.
HTH, Jochen
-- Jochen Daum - Cabletalk Group Ltd. PHP DB Edit Toolkit -- PHP scripts for building database editing interfaces. http://sourceforge.net/projects/phpdbedittk/
- Next message: Josh White: "Re: triggers - INSERTED table"
- Previous message: Jochen Daum: "Re: performance on SET TRANSACTION ISOLATION LEVEL"
- In reply to: Adam Machanic: "Re: Need advice w/ table design"
- Next in thread: Sam: "Re: Need advice w/ table design"
- Reply: Sam: "Re: Need advice w/ table design"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|