× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



<Where a 1 in a certain position denotes allowed eligibility.>
That's way back in the day!

We have switch fields like that in a file or two, and in some apps we have some really bad relationships that you have to have a few drinks to get the mindset to work with it, we have state tables in some apps and we have some very nicely normalized systems some written by hand and others built in synon.

It's always something.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Matt Olson
Sent: Friday, October 25, 2013 9:53 AM
To: Midrange Systems Technical Discussion
Subject: RE: Anyone have a well normalized DB2 database and use RPG?

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.

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.