Re: Data Constraints Vs Application Constraints

On Thu, 10 Mar 2005 05:02:56 GMT, Jonathan Leffler <jleffler_at_earthlink.net> wrote:

>You're right - that is the most probable reason. But diplomatically,
>there is every reason to take it gently and make sure that it is
>actually incompetence and not something else.

Of course!

Most probable does not mean certainty :)

> Another probable reason
>is called 'ancient history'. Once upon a time, the DBMS did not have
>support for anything other than primary keys, and they've never gone
>back to fix up the design after the DBMS became able to support them.

But they had a while to fix that, at least for the new developments.

>And, it is better to find that out without calling people incompetent.
> It tends to get their back up without gaining you anything.

It depends a lot on what position you are, but it is true that is better to talk about the system than to talk about the people who built it.

You never need to call people incompetent in an explicit way.

>Agreed with the feathers. I'm not sure I'd classify portability as a
>normal reason - many, many shops have no concern about portability at
>all. And when it is a portability issue, it often means they've coded
>to a perceived lowest common denominator functionality.

But even if portability is a requirement, it is a lot better to implement the constraints using the DBMS.

>You don't have to lie - but it is worth spending time to establish
>that what appears to be the case actually is the case, before you burn
>your bridges.

Of course.

Regards Received on Thu Mar 10 2005 - 13:07:22 CET