🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: borland.public.cppbuilder.database.multi-tier
3 messages
3 total messages Started by Christopher Smith Sun, 15 Apr 2001 22:11
General Design/Normalization question
#666
Author: Christopher Smith
Date: Sun, 15 Apr 2001 22:11
7 lines
1226 bytes
Recent discussions in school have argued against higher levels of
normalization as being too detrimental to performance.  I've never worked
much beyond stand-alone applications.  Are there books/case studies/articles
that anyone knows of pertaining to performance tradeoffs for normalization
when doing database design?
Regards,
Chris
Re: General Design/Normalization question
#667
Author: mpowell
Date: Mon, 16 Apr 2001 14:02
24 lines
2045 bytes
I don't know of any off hand. The general rule we've adhered to is a balance
between usability and normalization. IOW, if you find yourself doing a lot
of JOIN's to resolve data references then it may be time to consider
consolidating some tables. Also, we try to keep our primary keys to a
minimum so as to avoid unnecessarily indexing tables just prior to queries
(simple and complex). For the most part, our primary keys are a single value
(DOUBLE PRECISION or INTEGER) and we feed GEN_ID() to them (starting from
the very bottom end, -2147483648 or something like that, generators default
to 0, but since GEN_ID uses an integer we find this works just fine).


"Christopher Smith" <smitty1each@earthlink.net> wrote in message
news:3ada280f_2@dnews...
> Recent discussions in school have argued against higher levels of
> normalization as being too detrimental to performance.  I've never worked
> much beyond stand-alone applications.  Are there books/case
studies/articles
> that anyone knows of pertaining to performance tradeoffs for normalization
> when doing database design?
> Regards,
> Chris
>
>
Re: General Design/Normalization question
#671
Author: Christopher Smith
Date: Tue, 17 Apr 2001 02:34
44 lines
2777 bytes
I guess I've been spoiled by doing small, stand-alone stuff in MS Access.
Haven't seen performance issues despite having elaborate joins.  Of course,
the datasets in question are motes in the eye of a beamy enterprise-class
application.  And in Access you have nice facilities like AutoNumber fields
to keep the keys sane.
I guess I should peruse some of the industry magazine web sites for
performance roundups.  However, my question might not be well answered by
such comparisons...
Thank you, though.
Chris

"mpowell" <mike.powell@transcore.com> wrote in message
news:3adafcc9$1_2@dnews...
>
> I don't know of any off hand. The general rule we've adhered to is a
balance
> between usability and normalization. IOW, if you find yourself doing a lot
> of JOIN's to resolve data references then it may be time to consider
> consolidating some tables. Also, we try to keep our primary keys to a
> minimum so as to avoid unnecessarily indexing tables just prior to queries
> (simple and complex). For the most part, our primary keys are a single
value
> (DOUBLE PRECISION or INTEGER) and we feed GEN_ID() to them (starting from
> the very bottom end, -2147483648 or something like that, generators
default
> to 0, but since GEN_ID uses an integer we find this works just fine).
>
>
> "Christopher Smith" <smitty1each@earthlink.net> wrote in message
> news:3ada280f_2@dnews...
> > Recent discussions in school have argued against higher levels of
> > normalization as being too detrimental to performance.  I've never
worked
> > much beyond stand-alone applications.  Are there books/case
> studies/articles
> > that anyone knows of pertaining to performance tradeoffs for
normalization
> > when doing database design?
> > Regards,
> > Chris
> >
> >
>
>
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads