I didn't realize that reply had gotten out, as I was typing it as a note to my self on my phone. But, essentially, I would still stand by the contention that most database are fully normalized because of performance, maintainability, and how difficult it can be to understand how to use a fully normalized database anyway.
What exactly do you mean by "well normalized" anyway? If you mean designed down to the fourth normal form or higher, and then de-normalized where appropriate to a more useful format, I agree with you.
Normalization takes out some very useful attributes - like optimizing for a particular query pattern. Or optimizing to make coding more intuitive or faster. Yes, you can build joins and logical files and other types of access entities to address some of those issues, but, when you get right down to it, joins and etc read more data off the disk and consume more processor cycles than using a record format optimized for the application.
It's hard to argue that, or that doubling, tripling, or even quadrupling the number of reads from DAS necessary to satisfy a query is less efficient and will take more time than a single read. Not to mention more processing.
This is a pretty basic issue with RDBMs, and is why other database methods, like network database models have been tried. None of them are as popular as RDBMs for many reasons, but that doesn't make RDBMs technology perfect. ;)
I encounter many installations where someone has misguidedly "optimized" a database by normalizing it far more than it should be. I've seen programmers frustrated by a query that runs too slowly, only to look at the explain and nearly faint. It is rarely necessary to join 40 or 50 tables... :(
On the other paw, I have seen installations where the database is well normalized, meaning as I described that above, and things run like greased lightening. If programmers are not always happy about the database, then at least the DBAs are equally unhappy about whatever compromises were made... :)
-Paul
On Oct 23, 2013, at 06:38 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:
He said well normalized. Not fully normalized.
I don't know. Every chance I have had to be build normalized database it
has performed beautifully. Design the database right and it will do most of
the work.
On Wed, Oct 23, 2013 at 5:31 PM, Paul Raulerson <paul.raulerson@xxxxxxx>wrote:
Oh phooey- the reason there are not many fully normalized databases on the
iSeries machines is the same reason there are nit many fully normalized
databases anywhere else.
A fully normalized database is clunky and usually performs like pig in
real world situatilns.
Typos courtesy of my iPhone and my fat fingers!
On Oct 23, 2013, at 5:07 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:
OK, I bit. Assuming a well normalized database, why not use embedded SQL?
What reason would you have for using RLA? SQL was designed for well
normalized databases. Why not use it?
And for the reason that there are not many normalized database on the
400,
it's because there is almost no one who works on an AS/400 (iseries) that
knows what a normalization is. In 30 years on this platform I have only
met
maybe one person who know what normalization meant (Excluding people from
this forum).
On Wed, Oct 23, 2013 at 2:25 PM, Matt Olson <Matt.Olson@xxxxxxxx>
wrote:
It seems if you don't use embedded SQL to access data, chaining becomes
a
nightmare in RPG in very well normalized databases or you get logical
file
"forests" where logical files propagate like crazy.
Most databases I have seen in RPG environments are not very normalized,
presumably because it's easier to chain to them when all the data is
just
there in one file rather than multiple nested files.
Thoughts?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
