Re: Dreaming About Redesigning SQL

Originally posted by Dawn M. Wolthuis

> andrewst <member14183_at_dbforums.com> wrote in message
> news:<3501104.1066657824_at_dbforums.com>...

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

OK, there are 2 separate issues here:

1. Should data integrity be "part of" the database, written in the language of the DBMS, or should/could it be a separate layer on top of the database, written in a different language.

Here, although my argument stated the former (part of DBMS) approach, I am open to persuasion that a separate DBMS-independent layer might be an alternative - specifically if a mechanism for such a layer is somehow better at doing it than the DBMS-level alternative. But only if ALL inserts, updates and deletes of data are controlled by this single layer. (I will leave aside my reservations about database independence, they aren't relevant here; in principal, the DBMS-independent layer could work).

2) Should there be a single point of data integrity control (whether in

   the DBMS or in a separate layer on top), or should it be built into    the various individual applications that use the data.

Here I insist that YES there must be a single point of data integrity control, i.e. if you have 3 applications then the architecture must be:

• ------ ------

App1 App2 App3 ... etc.

• ------ ------

  | | |

  v v v

Data integrity layer

            |

            v

Database

Without that, chaos reigns: you can have n-1 perfect applications with no integrity faults, then 1 new bad application buggers up the entire database.

Presumably you don't agree with my view here, otherwise your point that "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" doesn't make sense. It suggests that you would prefer to increase developer productivity at the expense of data integrity; though given that they all have a lot more code to write, that is a questionable advantage. Surely the fact that some new business rules can be implemented and tested ONCE in the integrity layer (or DBMS) rather than implemented and tested N times in N applications is more productive? Sure, sometimes a change will require all N applications to be changed also, e.g. to add or move fields on screens; but in that case, surely they should all apply the same new integrity checks, rather than each come up with their own variations?

--
Posted via http://dbforums.com