Re: (EOM) entity logic
Re: (EOM) entity logic
- Subject: Re: (EOM) entity logic
- From: David Holt <email@hidden>
- Date: Tue, 23 Nov 2004 10:18:13 -0800
I have found this sample chapter at o'reilly to be very helpful in looking at database concepts. It is from their "Java Database Best Practices" book. The chapter is called "Relational Data Architecture"
http://www.oreilly.com/catalog/javadtabp/chapter/ch02.pdf
David
--
At the end of his life, Ezra Pound observed to a friend: "Nothing really matters, does it?" Today I understand this. At the end, or close to the end, or closer to the end than the beginning, the value of what we once thought mattered is lost to us. Even survival, once so important, money, food, family, country, accomplishment, recognition, fame, even: Pound was right. He once said to Allen Ginsberg: "At seventy I realized that instead of being a lunatic, I was a moron."
Doris Grumbach
<x-tad-smaller>from Sunbeams: http://www.thesunmagazine.org</x-tad-smaller>
On 23 Nov 2004, at 2:30 AM, Paul D. Yu wrote:
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
_______________________________________________
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