Re: Multiple specification of constraints

"ben brugman" <ben_at_niethier.nl> wrote in message news:404dc537$0$3679$4d4ebb8e_at_read.news.nl.uu.net...
>
> >, the above example could be done just as easily using a view.
>
> No you can not, because you need a complete development cycle to
> get that implemented. A view that is not used in the application serves
> no function. To use the view the appliation must be changed.
> Changing an application is not trivial.

If you're suggesting mangling the application to get around a procedural deficiency, then the tail is definitely wagging the dog. What do you imagine is the long-term effect of multiple such "improvements"? In every company I've ever worked in, the biggest drag on productivity has been half-assed hacks like these, which not only rapidly decrease programmer productivity (trying to patch the patches), but eventually results in a brittle pile of drek. I understand the need for speed, and if the users absolutely require such a hack for a short-term goal, then so be it. But if the development department isn't then willing to put in place the right solution, it's not a department worth working in.

> > But
> > if the data is actually stored in the person name, then you've got a
> > maintenance problem. Every time a person changes department, you have to
> > edit his or her name too?
>
> Yes, you have to, but that is no problem.

Yes, it is a problem. If you can't see that, there's not much more to say... why aren't the users just hacking on their own MS Access database (which is a cost-effective solution for some trivial applications)? I expect that sort of solution from users, but not from an I.T. professional.

However, if the users don't care about this, then fine. But keep in mind they might just not know any better, whereas you're supposed to advise them (e.g. tell them that they shouldn't HAVE to do that, and at the next development cycle they could have a solution that wouldn't require that. Then see what they say).

Also keep in mind that in this case, the short-term fix makes the right fix much harder - now you have to go in and eliminate all those department names, right? Maybe not so hard, but annoying and pointless unless they absolutely needed the fix RIGHT NOW and are willing to pay.

> > The long-term consequences of that far outweigh
> > the tiny amount of time it might save you. Silly.
>
> The user satisfaction far outweight the long-term consequences of this
> solution.
> In the long term this can be mended.

Does the "long term" ever really come? Do you ever get around to "doing it the right way"?

> Usersatisfaction is not something that is silly.

It's silly to use this example as an example. If this is typical of your environment, then the company deserves what it gets - rapid disintegration of its applications. If that doesn't happen, then the apps are so trivial that such examples as the above don't matter anyway.

> We understand the consequences of this solution, your arguments against
this
> were allready mentioned when I gave the example.
> The example was specifically given to demonstrate that sometimes real live
> arguments can outweight the theoretical arguments.
> Why can you theorist not appreciate that others can have a preverence for
> a solution that is different from your solution.

Well, this is comp.databases.theory. Solutions have costs as well as benefits. It sounds like you've thought this one out, and if you decide for the quick fix, then so be it. That may be the right solution in this case - you know your environment better than I do. I would suggest that such "fixes" have dire effects in the short term - not just the long and medium.

• Eric