That's an interesting example but let's look at it a bit differently
(1) The apps ran with that format cleanly and correctly for 20 years. They got something right, and it was clearly not a poor choice when it was made.
(2) What makes you assume accessing a table is any less processor intensive than a simple masked lookup through binary data?
Especially assuming they are only looking for the status of (most likely) one or two bits? Bitops are very efficient on the Power arch. (Or in this case, even in ML.) I would lay even money that the Bitops are faster and take less processor and DASD overhead than a table lookup. (grin)
(3) If a poor choice was made, it was to scatter the same code all over the system, instead of encapsulating it and making it a callable routine of some sort. Had that been done, the code would need to be changed in one place, possibly without even changing how the code is called.
(4) I do normalize databases, and even understand the theory behind it all. But, speaking only from my experience, there is about a 50/50 split between cases where more normalization of a database makes the most sense because of maintainability and functionality, and cases where less normalization makes the most sense because of performance.
YMMV, etc.
-Paul
On Oct 25, 2013, at 08:52 AM, Matt Olson <Matt.Olson@xxxxxxxx> wrote:
I'm talking about normalization where normalization makes sense.
Let's take a real-life example.
There is a field in the database that is 40 characters long. It denotes how many widgets you are eligible for. It is a sequence of 0's and 1's. Where a 1 in a certain position denotes allowed eligibility.
Of course, the reality that 40 was a poor choice has set in 20 years later that this should have been a table ("AllowedWidgets" table) that would allow unlimited # of widgets as rows, instead of stuffing it all into a column because it was super easy to CHAIN to, and then this is the kicker, parse through a 40 character string (unwise from a performance standpoint) for every record in the table.
Now we get to move on with hundreds of hours trying to unravel this mess, rewriting many RPG programs, etc.
This is why we normalize databases, and unfortunately this wasn't the norm back in the day.
-----Original Message-----
From: Paul Raulerson [mailto:paul.raulerson@xxxxxxx]
Sent: Thursday, October 24, 2013 2:57 PM
To: Midrange Systems Technical Discussion
Subject: Re: Anyone have a well normalized DB2 database and use RPG?
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.
--
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
