Foreign keys
Busy getting ready for our US holiday; no time to blog, but it's worth noting that Richie is finding that foreign keys are getting in the way of tests. Alan had a similar experience not so long ago. I leave you with this thought:
Foreign keys === Static Typing
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
2 Comments:
I find I disagree with your analogy. I prefer dynamic typing but I also like foreign keys; so either I'm inconsistent or you're wrong. I choose to believe the latter.
Having worked on the same project as Alan, and experienced the same problems with foreign keys, I still say they are a good thing; particularly when you are dealing with databases that multiple applications and teams will use. Rigid and inflexible yes but at least predictably so.
In response I'm sure you can ask me if I'd advocate static typing for projects where multiple teams use the same objects. Here's my response:
In an object based application if multiple teams were using the same objects I'd suggest that different classes had class owners - that only one team would change any given class - everyone else would rely on the interface to the class.
Relational databases are used to store structured data. They are all about state, they contain no behaviour. The only interface you have is the schema: to provide a rich meaningful interface you need to add as many constraints as possible.
LET THE FLAMES BEGIN!!!
I'm using '===' in the strict mathematical sense meaning "kind of reminds me of".
In fact I'm not
* entirely sure I disagree with
* entirely sure I agree with you either
I'll write something more cogent later.
Post a Comment
<< Home