Foreign keys vs Static Typing
| static typing | foreign keys |
|---|---|
| provides metadata on the structure of the application, useful to tools and developers | provides metadata on the structure of the application, useful to tools and developers |
| helps prevent (programmer) errors entering application code at compile time | helps prevent (programmer) errors corrupting data at runtime |
| absence of static typing may be more than compensated by good unit testing | absence of foreign keys in a single-application database may be compensated for by good functional testing |
| adds overhead to application code maintenance slowing down rate of change | adds significant overhead to test code, slowing down rate of change of data and application code to new requirements |
| often requires moderate to significant test scaffolding | nearly always requires significant test scaffolding |
| first line of defence against human error | second line of defence against human error |
| Directing (as opposed to Enabling) | Directing |
| Help's prevent surprises: when a method says it is returning a Customer, you know you're going to get a Customer | Help's prevent surprises: when an order has a foreign key to the customers table, you know that there's a valid customer at the other end. |
Though, the thing that ties static typing and foreign keys closest together for me is the the faint retort of the bolt gun as yet another sacred cow is slaughtered. Of course, all you lispy/small-talky types were always hip to dynamic typing. Me though, I’d always been taught that big serious applications – where someone can lose their job – needed static goodness. Foreign keys too. And Checked Exceptions were the great new Java thing.
Update:Forgot about the directing/enabling bit. Also: to be continued.....
Update 2:Remembered about preventing surprises.
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
0 Comments:
Post a Comment
<< Home