Re: Dreaming About Redesigning SQL

andrewst <member14183_at_dbforums.com> wrote in message news:<3501104.1066657824_at_dbforums.com>...
> Originally posted by Dawn M. Wolthuis
>
> > topmind_at_technologist.com (Topmind) wrote in message
> > news:<4e705869.0310191137.57cbf1c7_at_posting.google.com>...
>
> > ...
>
> > That is not to say that it
>
> > is not important to protect the data, but that there are other means
>
> > of doing that. It can be protected with quality assurance (also
>
> > flawed, of course) on the sum total of all applications that maintain
>
> > it.
>
> >
>
> Great! So the data integrity is to be as good as the worst application
> that maintains it. Can you not see that the DATA is the really
> important commodity here? The applications are really just pretty user
> interfaces, and they should not be entrusted with full responsibility
> for data integrity. Especially when there are to be SEVERAL
> applications... Every time a new application is added that seeks to
> maintain (some of) the data, your QA team has to ensure that it
> encapsulates each and every data integrity rule for the data it touches.
> Ditto when the functionality of any of these applications is extended.
>
>
>
> What you advocate is what we had no choice but to do years ago, before
> database-level constraints existed. You built a screen to enable input
> of orders, you had to encode ALL the data integrity rules in the screen
> code; you added a second screen to facilitate bulk-input of many orders,
> you had to duplicate all the data integrity rules; client/server came
> along, and you rewrote the application in a new tool, rewriting all the
> data integrity rules in the new client language. Hopefully by this
> point you could move the data integrity checking to the server, and
> hopefully you did. If not, when web-enabled became the vogue and you
> re-wrote your application in Java, you had to recode all the data
> integrity again...
>

You are missing my point, but I'll play anyway -- Yes, indeed, there are benefits and risks of each approach. What I would advocate is not choosing a language that goes with the database with which to declare integrity constraints, but to choose an object language, such as Java, and make it so easy to use the right objects that incorporate editing rules and integrity constraints that developers will not only know they must use these as their standards, but also will be able to migrate the standards as needed and will want to use these standard objects.

I wouldn't put the editing rules with a screen -- I would simply align the "code" (i.e. type definitions, constraints) for the database with all of the other code (types, constraints) in an application.

However, by doing this, you tie your data persistence and all of your typing/constraints together so that the language to be used to maintain the data with all constraints is determined outside of the database selection. This makes an application more database independent and less language-independent. There are pros and cons to each of these. In my scenario, if you opt for a different database, no big deal -- especially if it is a permissive database and doesn't force you to encode it with fixed field lengths and other things the persistence engine need not care about.

The downside of this is that if you have another language or application that wants to use the same data persistence, then it either should make use of the typing/constraints established for the applications that use that data, or it must re-encode those constraints in the language of the application.

I also do not have a theoretical rationale for this, but a practical one -- from my experience, this saves money. Again, I'd like to launch a contest so that we have a better idea what components in various approaches to software development meet which criteria. My criteria is big bang for the buck. If someone is writing software for an artifical heart for me, I might have a more DOD-type QA approach to such s/w dev. I'm referring to the "average" information system -- customers, financials, sales, products, etc. for the average company (if ever there were one).

My point was to point out that the use of a database-centric language to declare constraints associated with data is a sacred cow and it doesn't necessary yield the best results, depending on the goals for a project.

>
> Imagine: when your data integrity is fully protected by the database
> server, your applications can change or be replaced as often as you
> like, and your data integrity is guaranteed not to be impacted.
>

Unfortunately, such protection often ends up to be the problem for agility -- just because we thought phone numbers were necessarily associated with a location doesn't mean they always will be, for example. Also, if a developer is not permitted to change these constraints, but must wait for such changes from others, that can hold things up quite a bit.

>
> How agile is THAT?

Not nearly as much as it sounds like it might be. Received on Mon Oct 20 2003 - 12:23:31 CDT