RE: Are people really using Identity constraints specified in
It's scoping, Mike. If the name entry into an employee database is done by the HR department, it's perfectly
reasonable to have the schema enforce the age constraint. In this case, the IT department (if indeed they
control the schema) is the servant of the HR department who is likely the servant of another HR group
reading the state or federal laws for employment. The actual case in the state I live in is that employment
is not constrained, but the number of hours they can work a week during the school year, the days of
the week and the precise range of clock time (say from 5 to 8pm) or the weekend, the time of year,
and the types of jobs they are allowed to do. Would that schema apply in the UK? Possibly not.
Is that a bit complex to put in a schema? Probably, but I can easily envision a large company operating
within a state that needs to ensure all of its divisions apply the same policy equally attempting to use
an operational schema to do that because they can create and update that easier than they can
force all of the distributed departments to use the same processor.
It is the convergence of hierarchical or networked authority resulting in scoped policy that declares
the means is not ubiquitous, the policy still can be. The general rule is, the larger the scope,
the looser the schema. It isn't means but application that determines constraints. The tradeoff
is that increased abstraction reduces performance, and spreading the business rules out increases
the processing required to complete a transaction.
The example you give below is a consequence of distribution of the application at a greater scope
than the design can support. The means is functional but the design is not fit.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format