Hi,
I actually had to write some Perl scripts to transfer user data from a
billing software's DB to Remedy ... and I was eventually slightly
surprised that the Remedy folks were really able to deliver a ER model
even worse then the billing software's model. But they did a great job
in accomplishing that goal ;).
By the way, I think that highly normalized databases (3rd is enough)
would support application development if the software designers put more
effort into object relational mapping.
I always found it much easier to map objects to a normalized DB. But I
guess some developers prefer cramming everything into a maximum of 1
table ;)..... implementing data integrity within the database, huh ?
Never heard of that .... foreign keys ? What's that ?
"And we have to stick to SQL 92 in order to support ANY RDBMS ever made
..." blah .. and so on ...
Jared Still schrieb:
>
> Comments embedded
>
> On Thursday 19 April 2001 15:31, Eric D. Pierce wrote:
> ...
> > As far as I know, structured denormalization is considered to be a
> > method for modification of a normalized design. There should be
> > disipline/method/rules that try to get the best performance increase
> > in a trade-off for the least collateral damage (extra coding).
> >
> > I get the impression that this is standard operating procedure,
> > documented in industry journals, and so forth.
> >
> > In your experience, what percentage of "real world" dbs are using
> > pure normalized designs?
>
> In my experience, DBA's are scum and developers lobby the managers
> with tales of how terrible life will be if they're forced to write code for
> a normalized database.
>
> I guess I'm saying that I can't recall starting with a completely normalized
> database ( just 3rd normal form here ) and then denormalize if we found
> it necessary for some reason.
>
> We've usually have had some denormalization in as soon as we started
> doing physical modeling. Sigh.
>
> If you're familiar with the Help Desk software 'Remedy', you will know that
> it has one of the worst schemas ever designed by man or beast. If you
> haven't seen it, you would have a hard time imagining it. Yes, worse than
> Finanacials, Lawson, SAP, etc.
>
> ( 'where is he going with this?' you ask )
>
> One of my fantasies is to build a help desk system that runs on a normalized
> schema, open source it, and put Remedy out of business. The schema
> is that bad.
>
> >
> > Has this changed as hardware becomes more powerful and cheaper?
> >
>
> Hardware, and Oracle has improved in it's ability to join. I assume other
> databases are faster than in years past as well.
>
> > pss, aren't you *ever* going to tell us what happened at your last
> > job?
>
> Sorry, thought I had.
>
> My previous employer laid off several folks. I wasn't among them however.
> Damagement decided to take this opportunity to redeploy several positions
> to HQ in Houston TX.
>
> If you've spent any time in the Pacific NorthWest, you may understand why
> I chose to stay here. Likewise if you've been to Houston :)
>
> ( hope I didn't offend any Texicans :)
>
> I'm taking this opportunity to attempt a slight career change and get into
> the contracting side of things.
>
> Jared
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Jared Still
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
> -----------------------------------------------------------
> This Mail has been checked for Viruses
> Attention: Encrypted Mails can NOT be checked !
>
> ***
>
> Diese Mail wurde auf Viren ueberprueft
> Hinweis: Verschluesselte Mails koennen NICHT geprueft werden!
> ------------------------------------------------------------
--
Regards,
Stefan Jahnke
BOV AG
@:D2 Vodafone, Abt.: FIBM
AMS-Gebäude: E6 R08
Tel.: 0211/533-4893
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Stefan Jahnke
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
