Re: Multiple specification of constraints

"ben brugman" <ben_at_niethier.nl> wrote in message news:404c94a6$0$282$4d4ebb8e_at_read.news.nl.uu.net...
>
> >
> > I'm still very confused about the example. What did you have, what
> changed,
> > and how did you make the change easily?
> >
>
> During a visit of one of the consultants (a developer as wel) users said
> that there
> was no function (or button or easy way) to get only the members of a
certain
> department.
> There was a selection function on part of the membersname, but no
selection
> on dept.
> The name of each member was extended with the departmentname, the users
> could use
> the function build for searching names to search for members on that
> department.
>
> Example :
> Before : Smith
> Jones
> Anne
> Britta
>
> After : Smith Bicycle_refurbis_dept
> Jones red_tape_dept
> Anne Bicycle_selling_dept
> Britta Make_A_Hole_In_paper_dept
>
> Before on had to search for all the names or on a part of the name, now
one
> could
> just give 'cycle' and you got all cycle related departments.
> (In the actual case the departmentnames were shortened to just a few
> letters.)
>
> There was no change in the database, there was no change in the code, but
> the users got (within the visit time of the consultant) a workable
solution.
>
> If this had been done in accordance with all relational database rules, a
> departmentname is not part of a membersname, so a seperate field should
hold
> the department. Code should be written to get all members of a department
> and the userinterface would have to be addapted.
>
> The solution prevented a develpment cycle to get that function to the
users.
> (A development cycle is a time consuming and costly 'thingy' in most
> organisations, because it involves the specification, development, testing
> getting the result to the customers).
>

So now someone entering a new person had to type their department name right in with their personal name? Or was this done via the query itself? While a bit silly, the above example could be done just as easily using a view. 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? The long-term consequences of that far outweigh the tiny amount of time it might save you. Silly. Received on Mon Mar 08 2004 - 17:49:12 CET