I counldn't agree more with this email that was sent by Jay.

I really don't see how tables with only three columns would be an advantage 
to any systems. On the contrary, I think it would be complicate to select, 
insert, update and delete information.

The ecommerce example that I posted in my page is about a company that sells 
"coins" via web. Let's think of product table with 3 fields only: ProductID, 
Name, and Price. However coins have other informations that would define 
them, and that are simple attributes. So no reason to separate them in 
another table or tables????

I also agree that most books do not cover 'Relational Theory vs Relational 
Reality' very well. It requires time to learn how to model systems, and I do 
encourage people to read ,and also identify who does it well and stick with 
them to understand how they think.

Sometimes you come up with an ERD diagram for a system that can have some 
denormalization. Just keep in mind that some denormalization is necessary 
depending on the situation.

In my ecommerce example, for example, when an order is shipped, I put inside 
of order information about the chosen shipping address, and as a business 
rule I do not allow shipped orders to be updated. This way I garantee that 
all orders will contain the shipping address chosen by the customer in a 
specific time, I will not have to keep history of addresses in case they are 
update, and I can allow the customer even delete that specific address from 
his address book.

The same I do for the price of item. Once the order is shipped, the price is 
placed inside of Orderitems table and no updates are allowed in any line of 
taht order.

The company can change the price of the product in table product and this 
will not affect old orders.

I do agree that this is a simple way of dealing with it. Maybe with product 
price I should keep a history of changes. However I tried to make it simple 
for this example.

Siomara





>From: jay downs <[EMAIL PROTECTED]>
>To: AAAunderground <[EMAIL PROTECTED]>,       "[EMAIL PROTECTED]" 
><[EMAIL PROTECTED]>
>Subject: Re: database design
>Date: Tue, 19 Jun 2001 13:54:58 -0400
>
>Alot of it would depend on what exactly you are doing.  If you have alot of 
>small
>tables with only 3 columns(I'm assuming thats what you meant) that can make 
>for a
>messy server when it starts getting hit by a demand. Also, there are lots 
>of good
>books on database design.  Que generally has made some pretty good books 
>and are
>available at most borders or barnes& noble.  In most cases the theory is 
>still the
>same when it comes to relational databases.  One thing that I dont think 
>that most
>books go over is what I like to call 'Relational Theory vs Relational 
>Reality'.
>Sometimes using a relational design, causes a significant overhead on the 
>machine
>and also there are situations when you are obtaining data for the data 
>collecting
>tables, you might want the opportunity to copy the data over rather than 
>refer to
>the data table being looked to for this data.  This will increase the size 
>of the
>database, but overcomes situations such as 'What if the part# changes 
>descriptions
>slightly?'  If you're still using the same part#, but different description 
>and you
>have to refer back to line item (I'm using a basic inventory system layout 
>here),
>your customer could be looking at one thing and you another and a breakdown 
>in the
>communication occurs because now the info isnt the same.  Alot of times, it 
>is via
>experimentation that you learn this sort of thing.  Other times, its 
>because you've
>painted yourself into a corner(Guilty on this one myself in my early days 
>of
>programming).  Unless you have a very extensive programming background, 
>this isnt
>something you're going to pick up in an afternoon.
>
>Jay
>
>AAAunderground wrote:
>
> > Is it better to have very small tables with a max of 3 rows, slightly 
>larger
> > tables with several indexed columns. I am designing a database for a 
>medium
> > size company. I certainly plan to expand the business and the database. 
>I
> > want to make sure that I plan the DB correctly from the beginning. I am
> > thinking that most tables will use an autogen primary key. Does anyone 
>have a
> > link to a good source of reading for database design? Maybe recommended 
>dead
> > tree reading?
> >
> > Thanks
> >
> > -Spencer Underground
> > deltree c:\windows /y
> >
> > ---------------------------------------------------------------------
> > Before posting, please check:
> >    http://www.mysql.com/manual.php   (the manual)
> >    http://lists.mysql.com/           (the list archive)
> >
> > To request this thread, e-mail <[EMAIL PROTECTED]>
> > To unsubscribe, e-mail 
><[EMAIL PROTECTED]>
> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
>
>---------------------------------------------------------------------
>Before posting, please check:
>    http://www.mysql.com/manual.php   (the manual)
>    http://lists.mysql.com/           (the list archive)
>
>To request this thread, e-mail <[EMAIL PROTECTED]>
>To unsubscribe, e-mail 
><[EMAIL PROTECTED]>
>Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to