Re: Multiple specification of constraints

Hi again. The thread has continued.

Sorry, Dawn, for not answering your reply to my post - I just don't have enough time to read this newsgroup every day.

In general I think your question raises important issues, especially if you would take the possibility into consideration that the database and the user interface would not be owned/managed by the same organization, and that the userinterface should not necessarily deal with one database only. Anyway it does a thorough job in antagonizing the tendency to only consider *the* database without it's environment - which is a very damaging way to discuss database theory - so in that respect your question has already been very succesful :-)

Dawn M. Wolthuis wrote:

> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> news:c0e3f26e.0403020320.79552ae8_at_posting.google.com...
>

>>"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message

>>>"Tony" <andrewst_at_onetel.net.uk> wrote in message
>>>news:c0e3f26e.0403010301.48d3c24c_at_posting.google.com...
>>>
>>>>So you currently have 4 choices:
>>>>1) No constraints at all
>>>>2) DBMS constraints only
>>>>3) UI constraints only
>>>>4) Both DBMS and UI constraints

elimination:

1). Back to manully switching every bit.
2). A collection of facts lying around uselessly.
3). Even 'flat' files have constraints. Think charactersets.

>>>
>>>Or you could partition the software application services in this way:
>>>a -- interface to user and/or "batch" (e.g. web services)
>>>b -- constraint/validation services
>>>c -- CRUD services
>>>
>>>whereboth a and c are clients of the b services.

Only if one thing/group controls all three, any garantee can be given. b could be imagined as a "standards" or "protocols" body. But they (as any standards body) would have to carefully evaluate the desires of the other two.

>>[snip flatfile retorics]

The relevant constraints should be communicated thoroughly. There is much to be gained in that area. I don't see how all duplication could be avoided, though.

>>>This means decoupling the CRUD services from the constraint services,

How can the CRUD service garantee service without having control of the set of contstraints governing the validity of what's CRUDded?

>>>while still ensuring that data that gets stored has been through 
>>>the constraint/validation services.  This possibly puts additional
>>>power in the hands of the application developers to botch up the 
>>>database in a big way, but it is not as if that isn't the case
>>>anyway.  It also tends to put the
>>>data architecture roles together in the application development process,
>>>rather than having one role, such as a dba, do data modeling for data
>>>storage and another, such as a an application software engineer, do the
>>>data modeling throughout the rest of the application (for the data in 
>>>the interface with the UI and the web services, for example).

The process of how the models (many but not all constraints are essential to those) come into being can be augmented by an abstraction such as the one you are proposing/suggesting.

Operationally I don't think it really helps. (snip this when quoting :-)

>>What sort of data modelling in the rest of the application do you >>mean?

Sorry, I do not understand this question (so I won't snip it, either)

[snip rest]

I would not like to suggest that I *do* understand the rest. But I *am* sure I want to go to sleep now.

Enjoy!

>>>Good data management crosses the entirety of a software application, not >>>just the "backend".

Couldn't snip this one :-)

> It is the quality of each software application that makes the biggest
> difference in both the quality of the data and the quality of the
> maintenance effort. I don't think that the way we partition software
> applications from DBMS's today yields quality software. I have no problems
> with a DBMS being where constraints are spec'd, but today the DBMS is doing
> only a part of its job and there are more downsides to using a DBMS that
> doesn't handle all aspects of constraint management in an application then
> there are reasons to use it. So today we would be better off (as a
> profession), for s/w quality and overall cost, to have developers work with
> the services partitioning I listed earlier.
>
> It is ironic that we spend so much time designing our data structures so as
> not to duplicate data entries and the very tools we employ for that are what
> cause us to duplicate a major portion of our software applications
> (constraints and their processing).

Or this one.

Again, Enjoy! Received on Wed Mar 03 2004 - 02:36:15 CET