Re: foundations of relational theory?

"Tony Gravagno" <g6q3x9lu53001_at_sneakemail.com.invalid> wrote in message news:m9frpv4cnne4ud0li8f67ll0oveeefif38_at_4ax.com...
> A relational
> DBA can make the same mistake of improper definition as a MV coder can
> in his app code. In both cases the error would be caught and fixed
> immediately.

Agreed. (Although perhaps "immediately" is a bit optimistic. :-)

> Granted, the possibility for error is increased if an MV developer has
> multiple entry points into the app for database manipulation. But a
> properly designed app doesn't have a multitude of entry points for
> maintaining the same data, update routines should be consolidated into
> a manageable number of entry points, and all programs should use the
> same routines. Again we come to the point where proper maintenance of
> the database becomes the responsibility of the application developer
> and his/her understanding of proper design - this is independent of
> the database model. Neither model guarantees success, each model is
> subject to the understanding of those who implement it, so I'll
> maintain that neither view is right, but given a proper implementation
> both views are just as valid in this respect - neither view is wrong,
> they're just different and deserve equal understanding.

It does strike me that there are some advantages to NOT separating the role of DBA and application designer. Because I don't want to have my c.d.t. membership card revoked, I'll add that these advantages are "merely" practical ones and possibly even anti-theoretic. (Clearly I just made that word up; I hope it's sufficiently evocative that you know what I'm connoting.)

I would expect this advantage is only present in situations where the overall system design is below some complexity threshold.

I have worked on systems which did *not* have central integrity control, not even foreign key enforcement. We had scores of developers working on the system with dozens of different apps. The approach didn't work very well. But I could imagine it working well enough when there are few enough developers that they are all in constant contact.

But I'll still pitch declarative constraints rather than procedural ones. This difference is hard to appreciate until you've used the declarative approach enough.

Marshall Received on Tue Oct 28 2003 - 05:02:59 CET