> >
> >
> > Mike,
> >
> > Normalization does not really affect the ability for multiple users to work on a single record. That has to do with your buffering/record locking strategy and how you separate the data entry tasks. With an optimistic record locking strategy, user1 could work with fields 1 - 5, user2 could work on fields 6 - 13, etc. No conflicts would occur.
> >
> > Keven,
> >
> > Mike is correct in saying that these records should be normailzed. For example, let's say that the boat being sold is a Kirby 25 - how many Kirby 25's are going to be sold. This is a fairly common boat in these waters (Bruce Kirby is the designer of the Laser and designed an America's Cup yacht.) If this is the case, you don't want the users to type "Kirby 25" as the type of boat for each sale - you would normalize this out into a "Product" table. The "Kirby 25" would simply represent a product in that table. If you are selling that boat with an inventory of sales, the Main would be another record, the Jib would be another, the 'chute would be another. Sales are Sales are Sales. The table sturcture for grocery store sales would be very similar to the type of structure you would use for boat sales.
> >
> > For more on normalizing tables, take a look at this article:
> >
> >
http://www.datamodel.org/NormalizationRules.html> >
> > Ken
> > You shall know the truth - and the truth shall set you free. (John 8:33)
>
>
> I understand what you are saying.
> The people I am working with are doing everything on paper.
> What they have asked for is a way to save time in printing forms
> Not to do sales. Having said that I should go ahead and build the tables now
> so that if and when in teh future I don't have a mess with one large table.
>
>
> I think I will move this out of theis thread
See my reply to your other post.
Ken
You shall know the truth - and the truth shall set you free. (John 8:33)