So, I'm busy revising for my M359 (Relational Database) exam. Due to take place in the morning and I've come across some material in Block 4 which illustrates an issue I have with some aspects of the course material, that is, the choice of real world examples
In the OU material good coding best practice and coding concepts seem to appear as disparate ideas, whereas, in a commercial setting it's much more likely that a competent developer will command both in equal measure.
Often, in the course material, I have read about a system or IT approach whilst being told to ignore the usage because it would not occur like this in a real setting. The scenario can then change and rather than the example evolving naturally, like a real business/system, it can't, because we're stuck with a limited abstraction, so instead we are told to simply reverse out some of the functionality and see what happens when we take a different approach. It's an economical way to create a fresh point but I think there are more natural progressions of systems in real business. As an IT professional when the course is concerned with concepts I'm familiar with I don't find it hard to extract the point being made whilst ignoring the implementation but I fear for my skills in enforcing a distinction on those areas of material which I find less comfortable.
The example I came across today is regarding check constraints (They ensure only data of a certain type in admitted into a database either based on other records in the database or the values of the data being inserted). Here is the example given in Block 4 of M359:
I cannot think of a worse example of using a check constraint. This is business logic which should be miles away from the database. Not only is this logic in the database layer it is also coupled with the table definition. Double trouble!
If we want to change the minimum age of a customer we now have to drop this constraint and re-build it but first we've got to find the logic in the first place. A check constraint: the last place I'd look. This is doubly bad because if we attempt to add a twelve year old customer to the system we would expect a nice message to the user along the lines: “Customer too young. You know the rules!”. Instead the database code throws a horrible database exception. We now must either return the exception's message to the user, which would be mind boggling to the average user, or display a generic message along on the lines "The database has sustained a lethal internal injury, sorry you are finished here." So now we have a bewildered user who keeps getting a scary error message every time they add this user.
It is not until we get to Block 5 that we encounter:
...
...
So the amount of logic we have in our database is a design choice but what are the repercussions of, for example, enforcing a minimum customer age as a check constraint? I personally think this is a bad design choice so the approach needed justifying - all the way to the front end. If there is a code sample you wouldn’t expect to find it in a production environment it should be introduced to the student surrounded with barb wire and dunked in dung.
