Re: Data Constraints Vs Application Constraints

From: paul c <toledobythesea_at_oohay.moc>
Date: Wed, 09 Mar 2005 18:49:09 GMT
Message-ID: <FyHXd.620540$Xk.454974_at_pd7tw3no>


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

Wow! You mention plural databases so there must be lots of tables. Sounds like they have implemented a file system on top of their dbms's.   If all constraints except primary keys are checked by application code there must be lot of it and even if they have some kind of framework to invoke common code one has to wonder how consistent / reliable that is, not to mention how to verify / audit that it is all being invoked when it should be, how transactions are recovered / undone after machine failures, etc. As they say "a man with two watches never knows exactly what time it is". Sounds like they may have many watches!

Makes we wonder what reason(s) they gave for hiring you. If the description is accurate and without knowing what the applications it is still easy to predict that they will have all kinds of situations where

   incomplete transactions are recorded, orphaned rows/items etc. So there will be plenty to do. Certainly does smell as if your job is going to be as much political as technical although upside may be that your job is secure for years as are those of whoever does the app code!

p

ps: I once had to present my opinion of an airline system to non-technical execs. In fact, some of them didn't even speak English. So I drew a cartoon of an airplane that had wheels galore. I got somebody to translate 'if this system were a plane it would have too many wheels'. If you have the ear of a sympathetic exec, maybe you should be describing these databases as having too many files! Received on Wed Mar 09 2005 - 19:49:09 CET

Original text of this message