Re: Multiple specification of constraints

>
> Data from an external source can be made to appear as part of the database
> in many different ways - web services, imports and exports, DB links, etc.
>

There are law, management or other instances do not allow for linkage, this is no option. Requirements are not only dictated by ??? automation or model rules, but also by laws, what people want and by economical constraints (money and time).

The example (a database were debts and 'bad' repayments are kept) is existing
and governed by rules dictated in the law. I know this is a theory group, but the example is from the real world. (Sorry for that).
(In the given example people explicitly wanted a non linked database. Reason for
that is that banks are allowed to check this registration if somebody applies for
a loan or a mortgage, but banks can not check this registration just to sell you a
loan or mortgage.).

Example of an economical constraint :
If something has to be build before a certain time, within a certain budget, it
is often cheaper to use the skills which are at hand than to obtain skills for
the 'best' solution.

An example of this :
A dropdown 'box' or 'window' was needed to display the names of 'members' of a department. (This is simple to model and simple to build). The programmer
at hand did just include the department name to each 'member's name and if now a selection on the department was done the dropdown 'box' only presented the 'members' of the given department. Offcourse also the 'members' which had
the department name woven into their name became visible. (He just altered the names of the members at the given site). This was implemented in a very short time, the users where immediatly happy with the
solution. This solution did hardly cost anything, the users were impressed. And at first I did think that the solution was totaly wrong and should be modelled
and programmed correctly. But I think here a programmer made a very creative solution for almost no cost at all. And the users were impressed and happy with
the solution. (Probably more so than if we had given them a 'correct' solution to
their problem but at a later time. This type off occurences problably generates
more orders for us than a correctly modelled and build solution). (Modeling and building the solution and delivering this with the next release would
take some time and cost some money.)

I know this is practise and not theory, but I always tend to think in real life situations.
My appologies for that in this theory newgroep.

ben brugman Received on Fri Mar 05 2004 - 18:24:24 CET