First, some comments on items in the article or posts...

> I will acknowledge how tempting putting logic in the database is

How do you define "logic"? Do data integrity rules count as logic? Others have broached this very question. A common example that makes the demarcation between integrity and "business rule" fuzzy is referential integrity. One could argue that it is a rule that a parent row must exist prior to adding the child row. I agree with Adam but will phrase it slightly differently. Data integrity rules span all applications and should survive changes in the middle-tier.

> Flexibility decreases as logic increases.....

NO! This really should be "As flexibility increases so does *complexity*." Stating that logic increases or decreases makes no sense.

> What I am saying is that the database can not and should not decide what is valid data.

Taking this concept to its extreme you could end up with multiple applications writing different data into the same column and ending up with crap. App 1 could think that only values FOO and BAR are valid while App2 might only think that CRAP and MORECRAP are valid. While it is true that the applications decide on what valid meaning can be derived from the data, the database should not trust that the application wrote that data correctly. The database should *also* check that data for validity. Those rules should be apply any and all applications otherwise it is different data.

> Databases can be designed to scale out but it is not as easy as

> scaling up, most consultants take the easy road

This is backwards. Databases scale UP easily. Scaling UP refers to putting the database on better hardware. Databases do not scale OUT easily. Scaling OUT means adding additional database servers that work in a cluster or load balancing environment.