Re: (EOM) entity logic
Re: (EOM) entity logic
- Subject: Re: (EOM) entity logic
- From: "Paul D. Yu" <email@hidden>
- Date: Tue, 23 Nov 2004 05:30:15 -0500
Database design is well described in the database world. The primary concept in the database world is normal forms. The reasonable position of the a database is to be in 3rd Normal Form, where the idea is to reduce the redundancies and repeating groups in the tables. One can take it to the extreme by moving to 4th and 5th normal form, but I've found 3rd is good enough.
For example:
Budget Table (denormalized)
id
plannedQ1
plannedQ2
plannedQ3
plannedQ4
could be expressed as
id
quarter
plannedAmount
The database design or EO Model is the MOST important thing you need to get right, especially if you are starting a new project. It is the foundation of you new building in cyberspace. If you modeled your foundation incorrectly, it will be very difficult to fix later and it WILL affect your application design adversely.
Hope this helps...
Paul
On Nov 23, 2004, at 2:13 AM, email@hidden wrote:
From: Jeremy Matthews <email@hidden>
Date: November 22, 2004 11:40:53 AM EST
To: email@hidden, email@hidden
Cc: Subject: (EOM) entity logic
After seeing an array of projects, the most important thing I've taken away is the logic of the tables themselves.
From these different projects I have seen a large variance in logic in just a few developers; some with one or two giant tables that work OK (albeit a bit slowly), and others with 20 tables with enough relationships to choke a horse.
Doesn't the need for logic dictate that we should ask ourselves if a separate entity is really necessary; if that data is truly "different" enough? Where do you draw the line? Any experiences from best practices?
Thanks,
Jeremy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden