Quote:
Originally Posted by gaming_mouse
It is static. It doesn't matter what you consider it, it is data integrity. That calculation results in static data that will have certain relationships. You can query the db and determine if any of the complex rules have been broken, or if the data is valid. There is no fundamental difference between the example I gave and a foreign key constraint, or the constraint that a field must be an int. There is a practical difference only because databases provide easy facilities for the latter, but not the former, through accidents of history, ease of implementation, demand, etc.
Despite the thought that we are talking past each other, I think we have a fundamental disagreement.
My suggestion is that data integrity simply deals on the data storage level. I strongly disagree that what happens at the database level has anything at all to do with what happens on the code level. A well-designed database owes no consideration to what the code does with it, what kind of services use it, nor does the quantity of services matter.
Data integrity has a very simple definition: data is to be unique, non-redundant, and non-anomalous. This is not "my" definition. This is "the" definition. There is no such thing as a "flexible" and "expressive" schema design. Just like static languages are concerned with a certain class of mistakes, data integrity deals with a certain class of mistakes. For example, you have have a constraint table of valid country names (which will prevent misspellings), but you can't have a constraint table on ensuring a customer is joined to the correct country. The former is data integrity, the ladder is probably what you mean by business logic. This, of course, can only be solved by code or by human, and even so, there is no guarantees that the data is valid as it is the very expression of the uncertainty principal.
At the fundamental level, data storage is a very different concept than the languages that call it, whether that language is SQL, Python, C, or whatever. The languages you use to call and manipulate the data is a personal choice, but once again, has nothing at all to do with data integrity.
I think I'm confused by exactly what you mean by business logic. If you mean computing values and aggregates from a database, I don't think there is much debate here, but this, once again, is not a data issue, IMO.
Perhaps I'm just confused because I'm very comfortable working at the raw database level, and I don't see the problem from the same abstractions others do?