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

On 2/4/11 11:33 AM, caura wrote:

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

Seems like the alluded requirements suggest the data needs to exist in a particular format within the database, rather than being "edited" according to some rules defined either by the application that or by the user to whom the data will be presented.? In that case there are CHECK CONSTRAINT capabilities to ensure the data must be stored in the desired format within the database. Alternatively [and I have already stated my dislike of] User Defined Types can be created to extend a scalar data type, and both functions and constraints can be defined to ensure the proper formatting for storage and retrieval. The functions could of course exist for the retrieval directly against the scalar types, without the complexity of any UDT, and even be encapsulated in VIEW objects against which any reading\reporting requests would be directed. And rather than using INSTEAD OF triggers on those VIEWs used in reporting, simply directing the DML against each TABLE is IMO the better option.

That said, I must admit that I have always desired also, the ability to effect certain character editing and numeric editing directly from the SQL for easier "reporting" to an application, even if such function is not well aligned with the primary intention for what the SQL should provide. I had even suggested that the CHAR() function in the DB2 for i SQL should provide an extension of the second parameter, direct access to the EDTWRD and EDTCDE features available in DDS. :-) But of course we end up writing the functions ourselves instead of having them defined as builtin functions of the SQL.

Regards, Chuck