Re: How much of data constraints on database is enough?

I have to agree with all of you and I'm so glad to hear that I was not
crazy to think the way you all think. I like to keep the constraints
sync in database and application level as much as possible. Then
handle user-friendly validation in application level (as Drew
mentioned) and try not to waste IO cost of database round trip.

I've been working to Ruby on Rails projects for a while and I am
definitely a minority/not-popular-one to say things like data
integrity. As Josh mentioned introducing foreign key is sort of taboo
for them one of the reasons, because now you have to load the data in
the certain order... :|

There are so many good key words (phrases) you all mentioned, very
encouraging to hear:
-- "keeping logic close to the data"
-- "the RDBMS--be the final arbiter of data integrity"
-- "good communication among DB people and the rest of the teams"
-- "corrupt data is just too painful to cleanup"
-- "good database constraints make testing the application layers much easier".
-- "profile before optimizing"

On Jan 15, 2008 10:24 PM, Chris Mungall <cjm(at)fruitfly(dot)org> wrote:
> keeping logic close to the data is not very fashionable. Ad-hoc ORMs
> that lack solid theoretical foundations are in fashion.

I think this is very interesting, actually, and I agree, seriously :)
It is realistic. For a company (or project), it's not cheep to find
and hire a resource that is capable of doing what you all mentioned,
therefore cost of maintenance is expensive as well.
It is really a fashion thing maybe. I say that especially because of
working at Rails community, I see they are trying to re-invent all the
things database can do and had solved in application level all over
again.

Miho