"Directive 595 is as follows: 'Not null constraints give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution.' As such, please remove from all production databases." To find out how this ends: http://thedailywtf.com/Articles/Directive-595.aspx

I keep running into DBAs and data architects that keep trying the "we don't need foreign keys" argument. I always ensure they lose that argument (and stuff gets better, amazing!).

Though in all seriousness, what alternate universe are these people crawling out of?

That and the types who call their j-random database a "data warehouse".

I would be very interested in knowing how you manage to win that argument. The only sure way I know of is in a post-mortem after a major data corruption disaster, so if you can suggest a less dramatic angle of attack I'd love to hear it.

This guy's experience was almost entirely with front-end technology (pretty much just JSP's actually), and it showed in almost every engineering decision he made. The sad thing is that, there is an argument to be made for denormalizing data and not using foreign keys. That argument is not "they don't buy you anything."

I worked in a bank for a minute or three. Big one. The production databases ran without foreign key constraints enabled for performance. In the development environment, however, all constraints were strictly enforced.

Exactly the same for me and unit tests.

"They're nice, but we can do those once the product is finished". It didn't finish.

Well at least he got the thing with the Superclasses right (the first part)