|
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,plans to "display" it to the user. For specific editing, you could
Surely, the "Editing" of the data item is a function of the program that
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?
usable
-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
and userfriendly form.support
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
editing in any possible way.substringing.
The simplest editing in SQL ends up in esotheric casting and
Sorry, but I have never understood this huge black hole in a "modernTables
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
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
list
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
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
https://vpn.sallybeauty.com/,DanaInfo=archive.midrange.com+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<
list
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
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
https://vpn.sallybeauty.com/,DanaInfo=archive.midrange.com+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 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.
midrange.com
