Re: Dreaming About Redesigning SQL

dwolt_at_iserv.net (Dawn M. Wolthuis) wrote in message news:<6db906b2.0310200923.63c18da_at_posting.google.com>...
> 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.

Data integrity. Should it be the responsibility of the database management system or application code? "DMBS" I hear you cry. "It doesn't matter" I whisper. So long as it's maintained. You are writing some application code. You think you want to READ, WRITE & DELETE records - but you don't really. You want more. You only want to update the database if integrity is being maintained. Supposing there isn't any integrity checking happenning? Gee whiz. Bummer. I guess I'll have to use some standard function instead of doing a direct (raw) update. OK then. I will. Job done. Next! Received on Tue Oct 21 2003 - 09:46:42 CEST