Tag Archives: relational model

Things I used to be Wrong about – Part 1

I get very annoyed about politicians being held to account for admitting they were wrong, rather than forcefully challenged when they were wrong in the first place. Unless they lied, if someone was wrong and admits it, they should be congratulated. They have grown as a human being.

I am about to do something very similar. I’m going to start confessing some wrong things I used to think, that the world has come to agree with me about. I feel I should congratulate you all.

You can’t design a Database without knowing how it will be used

I was taught at university that you could create a single abstract data model of an organisation’s data. “The word database has no plural”, I was told. I tried to create a model of all street furniture (signs and lighting) in Staffordshire, in my second job. I couldn’t do it. I concluded that it was impossible to know what was entities and what was attributes. I now know this is because models are always created for a purpose. If you aren’t yet aware of that purpose, you can’t design for it. My suspicion was confirmed in a talk at Wolverhampton University by Michael ‘JSD’ Jackson. The revelation seemed a big shock to the large team from the Inland Revenue. I guess they had made unconscious assumptions about likely processes.

Relations don’t understand time

(They would probably say the same about me.) A transaction acting across multiple tables is assumed to be instantaneous. This worried me. A complex calculation requiring reads could not be guaranteed to be consistent unless all accessed tables are locked against writes, throughout the transaction. Jackson also confirmed that the Relational Model has no concept of time. A dirty fix is data warehousing which achieves consistency without locking by the trade-off of guaranteeing the data is old.

The Object Model doesn’t generalise

I’d stopped developing software by the time I heard about the Object Oriented Programming paradigm. I could see a lot of sense in OOP for simulating real-world objects. Software could be designed to be more modular when the data structures representing the state of a real-world object and the code which handled state-change were kept in a black box with a sign on that said “Beware of the leopard”. I couldn’t grasp how people filled the space between the objects with imaginary software objects that followed the same restrictions, or why they needed to.

A new wave of Functional Programming has introduced immutable data structures. I have recently learned through Clojure author Rich Hickey’s videos that reflecting state-change by mutating the value of variables is now a sin punishable by a career in Java programming. Functional Programmers have apparently always agreed with me that not all data structures belong in an object

There are others I’m still waiting for everyone to catch up on:

The Writable Web is a bad idea

The Web wasn’t designed for this isn’t very good at it. Throwing complexity bombs at an over-simplified model rarely helps.

Rich Hickey’s Datomic doesn’t appear to have fixed my entity:attribute issue

Maybe that one is impossible.

State Change

A couple of weeks ago I started ‘preparatory drawings’ for a great work of the blogging art about application portability. That was hard. This is a quick caricature of the resultant pile of half-sorted words.

I decided to learn to code in Python, having dismissed several other options; including Java, Ruby, HTML5 and JavaScript. I’d even considered having another go at Lisp but dismissed that as impractical. Surprisingly, I didn’t consider Perl, for my laziness http://c2.com/cgi/wiki?LazinessImpatienceHubris.

Since I went to that Clojure talk I’ve referred to before, I can’t shake the feeling that there was something about immutability that I shouldn’t ignore. Conventionally, I’d replace the assignment of ‘Python’ to the variable LanguageToLearnNext with the new value ‘Clojure’. There would be no trace of the fact that the language I WAS going to learn next was Python – but I’ve written about it several times and now I’ve broken the links. If this was code, that would be a problem.

Variables have no time dimension. Neither does the relational model. Michael ‘JSP/JSD’ Jackson told me that. At around the same time, there was a buzz around parallel architectures and programming. There is again now, if you talk to people who are ahead of the game. They call it concurrency now. Physics has caught up, overtaken the hardware engineer’s RISC wizardry and erected its road-blocks again. We don’t know how to make our processes go faster; so there need to be more of them spinning. We live in a word of multi-core processors.

Clojure is immutable by default, which prevents concurrency scrambling coders’ brains. In Clojure, there is still yesterday’s LanguageToLearnNext and now there is a LanguageToLearnNext for today. Variables are so last century.

See: http://clojure.org/state if you want this explained properly.