Re: Data Constraints Vs Application Constraints

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 09 Mar 2005 08:37:16 -0500
Message-ID: <rpa3g2-du9.ln1_at_pluto.downsfam.net>


sparky wrote:

> Dear All,
>
> I have just started work at a new company as a 'Data Solutions
> Architect', and am now patently aware why they need someone with Data
> Architecture experience.
>
> There databases (be they Oracle or SQL Server etc) have no constraints
> other than Primary Keys (thank Codd, for small mercies) i.e. all
> 'relationships' are handled/enforced by the application.
>
> I am in the middle of proposing that as a 'first step', before I look
> at data integration etc that the integrity of the data should be
> enforced at the DB level as well as at the application level. Now the
> business arguements, to them will I imagine look pretty weak at first
> i.e. the systems working fine, without errors etc, so we don't need
> another overhead.
>
> As a consequence I am compiling a list of arguements for enforcing
> data integrity within the database (as well as within the app) and
> would be interested in anyone's opinions and/or experiences within a
> similar situation, and what they found to be the key arguements which
> won the business round.
>
> All thoughts, opinions, arguements, musings welcomed.
>
> Regards
>
> G
>
> P.S. we're not talking about a small company either....

A few notes from the top of my head.

Do you know why they did it that way? There was definitely a reason and you don't want to ruffle feathers by criticizing it before you know why it was done. The normal argument is for portability, if they code things in the client, their app will run against many databases. According to you this worked, so I would ask why change it? Technically it may be "wrong" but technically they somehow got it working and are a big company, so they must be doing something right?

The other hidden reason may be that they did/do not know much about databases, and you want to tiptoe-tiptoe around that one.

I was in a position like this, but a little different. I joined a shop of coders as a coder, and "converted" to being a database guy while there. Gradually my proposals and projects moved to the server (I had a lot of freedom there). But the company's entire mindsest, practice, habits, every reflex and thought, was based on the fact that they were coders. It can be lonely.

Finally, what specific problem in the app are you trying to fix? My projects brought them to the server through specific architectural improvements, to the logging system, the error handler, packaging and distribution, the login/licensing system, addition of cross-server support, enhancements to various crawling horror systems (taking 10 hour processes to 15 minutes) and so on. As the architect you need to look at the big app and decide what actually needs to be fixed.

So to sum up, leading with the idea that a working app has been done wrong is probably a bad idea. Better to examine it for missing spots, or spots that you can improve, and then implement that solution on the server (or more on the server), and let it sell itself over time.

Hope this helps.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Wed Mar 09 2005 - 14:37:16 CET

Original text of this message