Been a bit busy learning about databases of late. I am finding it incredibly challenging to understand the theory side of things in the way it is explained in the OU text. I also got the Battlestar Galactica   box set and had a job interview, birthday and ‘stuff’ to do.


I guess I’ll get the job interview out of the way first. I don’t mind if somewhere doesn’t want to give me a job having interviewed me, if they aren’t happy with me then it’s likely that I wouldn’t be happy with them so it is not a problem to not be offered a job. However if you have a fairly long interview process it does seem courteous to let someone know what the outcome was.

In this case the total amount of time the company recruitment process (for a very junior role) took was over three and a half hours of my life. I can understand why it is reasonable to be thorough and I have no issue with that. However in return for being prepared to invest that time it doesn’t seem unreasonable to expect to be informed of the outcome or to have a call returned.

In this instance the company is a well known UK website employing about 350 people. In its blurb it goes to great length to point out how much it values people and what a paradise it is etc. etc... The experience I have is that the truth is quite far from that so perhaps a bullet dodged.


In terms of computing I have been getting stuck into M359 which I am finding more challenging then I think it needs to be.


Last year I read a good book about databases (Database design for mere mortals, Hernandez 2013) and this came across as a sensible way of doing things. My module seems quite the opposite but I have a feeling that this is typical.

Relational theory is old and fairly tedious. The education of it is in general based around the idea that there are no databases, you cannot learn from what is around you or anything that has happened in the last forty years, you must start with the dry theory.

It does seem rare, if not unique, to come across something in this day and age where step 1 is to forget everything you know about the thing you are modelling and then try to make something functional out of thin air. I think that is almost a perfect description for the painfully clinical approach taken to the subject by the module so far.

In places multiple re-readings of large sections of the material are required for them to make sense which can make it very time consuming. In fact for a module that should be part time I am finding that the reality is that an almost fulltime commitment is required to make progress and even then I do not find that I am entirely satisfied with my performance in assignments.

I think the worse part is that the author of the material acknowledges that in some places students will be required to go over the material multiple times for it to make sense- surely an obvious indication that what has been done could have been done better.

This frustration carries through to normal forms where a sensible analysis of what is being modelled would take care of most (if not all) considerations, Hernandez provides an explanation of how he achieves this in an appendix that is surprisingly not the most exciting read of the century. It is frustrating to struggle doing something that is difficult for the purpose of being difficult rather than achieving a solution.


Fortunately I think the clear as mud part of the module may be behind me since SQL has started to appear, so I will be able to get back to mashing my face against the keyboard until something sensible appears on the screen (hopefully).