>> Ok, lets think about the job responsibilities of the back-end in a
>> modern-day program: it is responsible for making sure its data ok.
>> Furthermore, it's NOT the job of the middle-tier to ensure that
>> your data is valid: like I said, that's the job of whatever back-end
>> you're using.


> Travis,
>
> It is the job of the database server to enforce the domain constraints
> on the data. It is the job of the business logic tier to enforce the
> business rules on the data. This is a point that is often misunderstood.
>
> For example, a city field has a domain that allows and valid city name but
> the business rules say that only Canadian cities are allowed, what should
> the database use as a constraint and what should be enforced as a business
> rule. If the middle tier object is designed well it will much easier top
> change a rule at that level then it would to change the domain definition
> for the database when the client starts doing business in the US.
>
> Business rules are expected to change over time, domain constraints do
> not chane.


Hi Jim!

I agree with Travis on this one. In todays databases, we always mix metadata and data (which I don't like at all, BTW), meaning that tables always have real application data like the city in your example, but they also have organizational data like PKs that don't really relate to the business problems but they are there to resolve organizational issues. So it's data about data (metadata).

IMO, all kinds of metadata should be handled by the back end. PKs should be created and maintained by the back end, RI should be maintained by the back end, and so forth. Logical issues like your cities example should be handled by the middle tier (of course).

However, the point that was originally made was that data could be in an invalid state (from a technical point of view) if metadata like the PK wasn't assigned initially, and that was what Travis tried to respond to.

IMO, everything that can put data in an invalid state (cause error messages and alike) has to be handled in the back end. Whether data is logically correct (like in your cities example) is a different question, but it can not bring up the problems that were initially described by John.


Markus