🚀 go-pugleaf

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
> >
> >
>
>