Re: PF Compiled Files with Dictionaries vs. SQL-Created Tables

Rob,
I understand your explanation. But here's how I look at data. If I have
to do Maths on a piece of data, then its a number. If I don't, then its
"probably" best left as a string. There might be exceptions to the rule,
but they are definitely few and far between. I'm not worried about saving
a few bytes because I don't want to store the hyphens. Pssshhh. I think
the cost to store them is cheaper than the cost to reproduce them over and
over again. I'm in agreement with Eric's post. Edit code and edit words
in DDS PF is a no no.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/04/2011 04:01 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables






Bryce,

Storing edited data is one option. However, do you store all your dollar
amounts as edited strings? No. Yes, granted, that is different because
you will do math on dollar amounts and you will not on bank account
numbers (let's leave Mod10 checking out for now). What Luc is saying is
that DDS allows you to specify an edit code (or edit word) that "some"
query tools and that the default for external printer files is to respect.

I am not sure if Crystal reports, Excel or html output will respect edit
codes or edit words however.

An option to storing the data as an edited string is to read only via
views. Views can wrap the number as an edited string. For example, if
the table stores bank account as an 11p0 number then your view could use a

UDF to easily display that as ####-#####-##. You save space by packing
yet get the desired display. And all tools would respect that, if read
from the view.

Luc,
Is this what you are trying to get across?

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Bryce Martin <BMartin@xxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/04/2011 03:45 PM
Subject: RE: PF Compiled Files with Dictionaries vs. SQL-Created
Tables
Sent by: midrange-l-bounces@xxxxxxxxxxxx



So if the data entry program formats the data into a string properly at
the time the data is put into the table what is the issue? You then just
need to pull that data and display it. I'm sorry, but I don't see what
you are getting at?


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



"caura" <caura@xxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
02/04/2011 02:33 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables






Rob e.a,

<quote>
Editing of data is the responsibility of the application
</quote>
???

When I define data, I want the data to be clearly defined:
(for me, since it states "define data",
this indicates it has nothing to do with "business logic",
But everything with data definition.
I surely will be mistaken)

As an example:
If I define a bank account, -for me- It should ACT as a bank account.
(and not -as I read in some posts-
"every application that wants to display or print or ... an account,
should do and redo and overdo the necessary editing".

For me not quiet the way to create applications.
If every application that uses certain data should do editing itself,
This is a splendid example of the opposite of "reuse" and "inheritance"
and
"modularity" and all that modern stuff.

=> if I want an "Employer-reference" of a Belgian Enterprise,
It always has the format "0123.456.789"
So I want it to appear as such and this for every user and every
application.
(without the need for special functions as soon as the data is defined)
=> just a simple 1 time definition in DDS and certainly not
"left to the responsablity of any application that would exploit this
data"
(how many formats that would end up with?) .

=> If I want an Identity-number of one of our Members,
I want it to be shown in every application as a only-positive, zero filled
number.
= just a simple 1 time definition, and again please not "in every
application???".

=> a Belgian account always has the format "999-9999999-99".
Easy to define 1 time in DDS.

=> if I want to define a European account,
It should be able to edit it as a European account also:
BE12_3456_7890_1234 (with "_" as blanks)
Not possible in SQL but not possible in DDS either (=character-editing) .

Sorry but for me these examples are just every day data-manipulations for
over 20 years.
And SQL is unable to deliver these all basic and necessary functions ...

And no, I do not see my colleagues nor me defining and redefining such
trivialities in all our applications.


Luc

-----Oorspronkelijk bericht-----
Van: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Namens rob@xxxxxxxxx
Verzonden: vrijdag 4 februari 2011 15:43
Aan: Midrange Systems Technical Discussion
Onderwerp: Re: PF Compiled Files with Dictionaries vs. SQL-Created Tables

I am still waiting for the OP to define what editing they meant.


Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jason Abreu <jason.abreu@xxxxxxxxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 02/04/2011 08:06 AM
Subject: Re: PF Compiled Files with Dictionaries vs. SQL-Created
Tables
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Editing of data is the responsibility of the application and is defined
by business logic and not the DBMS. The DBMS is the bank, it just
reports what you've got stored, not how you should use it. "Using" the
data falls to your business logic, which should be encapsulated in your
application.

I have seen some solutions that try to encapsulate all business logic
within the DBMS, via stored procedures and triggers to do editing and
validating of the data. Those systems where also a nightmare to
maintain and suffered performance issues due to lengthy transaction times.

Jason Abreu
Abreu Innovations, Inc.
jason.abreu@xxxxxxxxxxxxxxxxxxxx
http://www.abreuinnovations.com/

On 2/3/2011 2:41 PM, DeLong, Eric wrote:

Hmm,

Surely, the "Editing" of the data item is a function of the program that

plans to "display" it to the user. For specific editing, you could
implement a UDF to reformat the data into an edited view... What is it
you are trying to do that you can't already implement in SQL?

-Eric DeLong

________________________________

From: midrange-l-bounces@xxxxxxxxxxxx on behalf of caura
Sent: Thu 2/3/2011 10:48 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: PF Compiled Files with Dictionaries vs. SQL-Created Tables



People create databases only for 1 reason:
To exploit those databases.

So first of all, the database should do what it's supposed to do.
Secondly performance comes in.

One major topic in exploiting databases, is editing the data into a

usable

and userfriendly form.
We are waiting for over 20 years for any support of editing in SQL.
As far as I know, V7R1 or any SQL for DB2 up to V10 still does not

support

editing in any possible way.

The simplest editing in SQL ends up in esotheric casting and

substringing.

Sorry, but I have never understood this huge black hole in a "modern
product".

PS: DDS has never supported any editing on "character-data" either.

Luc

-----Oorspronkelijk bericht-----
Van: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Namens CRPence
Verzonden: woensdag 2 februari 2011 19:53
Aan: midrange-l@xxxxxxxxxxxx
Onderwerp: Re: PF Compiled Files with Dictionaries vs. SQL-Created

Tables

On 2/2/11 5:54 AM, Gary Thompson wrote:

You might want to know about relative performance of tables created
using SQL DDL vs DDS:

http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performan



<
https://vpn.sallybeauty.com/systems/resources/,DanaInfo=www-03.ibm.com+syste



ms_i_software_db2_pdf_Performan

ce_DDS_SQL.pdf

I have an extensive understanding of that, and more. For example, I
am even aware of and understand the means by which the data validation
is implemented in the LIC "cursor" object; LIC internals, not published
information. I also have years of experience supporting the DB2 for i,
DB2/400, and its unnamed predecessor. Knowing that, perhaps readers can
even trust that my recommendations have value beyond the casual
observer\reader of some published information.

With regard to changing from DDS to DDL, the performance claims are
highly overstated if only for failing to temper their claims with
appropriate *warnings* for effecting such changes without full
understanding of the implications. I have been in the position of
supporting many who have made [small to massive] moves to DDL without
full understanding of the consequences, based solely on some simplistic
claim for [radically] improved performance. Those were unhappy
customers, and so I make attempts to warn others against making possibly
a big mistake by effecting change without both a "specific goal" and
having first investigated to "understand what will be lost and what will
be gained by the change." As alluded, some actually had to move back to
DDS to "recover" from their changes; surely not a move to be made on a
whim IMNSHO.

Regards, Chuck

CRPence on 02/01/2011 06:05 PM wrote:

And DDS even supports some features which SQL does not. I find
little value to change from DDS to use SQL DDL for existing
database *FILE objects, without some obvious need to access some
new feature provided by the TABLE; e.g. either data types supported
only in the SQL, or better integrity for numeric data. Without any
specific goal to be achieved by changing, what point is there in
change except change for the sake of change? That is, change
without justification is intuitively, not justified. Best to
understand what will be lost and what will be gained by the change,
to avoid remorse for having made the jump, and even more regrets
for having to move back in order to "recover" from the first
change. Changing "just because" to using SQL DDL versus DDS is, for
lack of a better word, daft.

<<SNIP>>

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

https://vpn.sallybeauty.com/mailman/listinfo/,DanaInfo=lists.midrange.com+mi



drange-l

or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l<

https://vpn.sallybeauty.com/,DanaInfo=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<

https://vpn.sallybeauty.com/mailman/listinfo/,DanaInfo=lists.midrange.com+mi



drange-l

or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l<

https://vpn.sallybeauty.com/,DanaInfo=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 message (including any attachments) is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and

exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---
--
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 message (including any attachments) is intended only for the use
of the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us and
destroy this message immediately. ---