3 random things
As the title implies there is no "theme" to this post it's just a collection of a few thoughts I've had or encountered recently.
First to get a bit of housekeeping out of the way I have a new Twitter account. http://twitter.com/MaxStocker. I am still currently responsible for the previous (TalentOyster) one but I will be transitioning away from one to the other over the next short while. (Note: I do know I need to update this in a number of places and I will do so over the next number of days. If after say the 9th of July you see an old account linked somewhere please send me an email and let me know).
On to the tech stuff. Url-rewriting in Apache. I generally think it's a good thing but boy, sometimes I think it can be abused. I've seen some really ugly stuff in the wild, and lord knows even for myself while regex is not my special calling in life I can write complex enough ones to make it tricky to follow.
But the one thought I had with this recently is that it *is* interesting to use it for validation purposes. And by validation I mean type-checking values passed for processing. The question is, is this a good idea. My feeling is that it seems like a nice plus, but also has the danger that it could lure the unsuspecting into thinking it's "enough" which it isn't.
Finally foreign keys, are they really needed? This is one of those ideas that I thought would make a good post on its own. And it probably would, but I lack the time at the moment to expand on it so a short entry will have to suffice.
I am not sure how "necessary" foreign keys really are any more. Now do note I am talking primary keys here so let's not go crazy. And I'm not talking about fields that *act* as foreign keys either but actual database "constraint" foreign keys that will only let you use value in X where it's the primary key of Y.
In theory it's a nice idea because you move data relationship into the database and out of the application. But do you really? No. Because in your application you end up having the same steps to deal with missing relationships, or changes to them, that you would have in the database regardless. The other side to this is that there is a "cost" in having foreign keys, I'm not going to talk about performance here because hopefully the database has that one sorted out but a cost in making the persistence system more restrictive then it perhaps needs to be.
I don't doubt that much of feelings on this has got to do with my experience, both with using databases that didn't have or support foreign keys or in having terrible problems migrating databases that did have them. And I also wouldn't recommend these ideas to someone who is new to databases or database development but... if you know what you are doing then I wonder.
This all may be a really stupid idea, I'm still thinking about it but ask yourself these questions. When is the last time that the constraints of your foreign keys weren't duplicated in your codebase? And do you really use cascading updates or deletes on foreign key changes? If the answer to those are no and not really then I don't really think you need foreign keys either.
|© 2008 Max Stocker|