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
Author: Christopher Smith
Date: Sun, 15 Apr 2001 22:11
Date: Sun, 15 Apr 2001 22:11
7 lines
1226 bytes
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
Author: mpowell
Date: Mon, 16 Apr 2001 14:02
Date: Mon, 16 Apr 2001 14:02
24 lines
2045 bytes
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
Author: Christopher Smith
Date: Tue, 17 Apr 2001 02:34
Date: Tue, 17 Apr 2001 02:34
44 lines
2777 bytes
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