Re: Dreaming About Redesigning SQL

andrewst <member14183_at_dbforums.com> wrote in message news:<3505221.1066738677_at_dbforums.com>...
> Originally posted by Mike Preece
>
> > 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!
>
> Simple as that, eh?

Yep.

> And if you are just one of 100 developers working
> on a project, your project management can just assume that you all do
> the right thing (use the standard function)?

Never assume! If you've read my other posts in this and other forums you'll have seen that I'm very much against people making assumptions. No. It must, of course, be a QA function to ensure the correct procedures have been followed before code is "released" or "put live".

> Or will every line of
> every programmer's code be subject to scrutiny by someone who infallibly
> spots EVERY single deviation from the business rules? Sure, that is an
> option. There may be 200 modules that have to write data to a core
> table. You can eyeball each one to ensure it does it correctly, or you
> can guarantee that they each do it correctly (or not at all) by ensuring
> that there is no possible way to bypass the rules. For a small
> database/application developed by one person, you may be right; for a
> large database with teams of developers writing code - I don't think so.

Funnily enough, I wrote the IO functions for a "Pick" (actually UniData) based system for the UK government. Quite a large and important application. And no - there is no problem.

Cheers
Mike. Received on Thu Oct 23 2003 - 12:10:35 CEST