More, actually, but not with Sgt. Pepper... When I got my first coding job, in the 1990’s, I was working through a certificate in programming. As I’ve mentioned previously (https://www.til-technology.com/post/fiat-lamp), my boss took me to the bookcase of technical manuals (which every IT shop had), selected about a shelf-foot of Oracle manuals, handed them to me, and said: “Here. Start reading.”
That was where I first learned about the soporific effects or technical documentation. But it’s also where I learned a fair bit about databases – data structures, data modelling, reporting, and more.
Amusingly, one of the last courses in my certificate was on data management. Since I had some practical experience by that time, I was looking into whether I could write a “challenge exam” to demonstrate my understanding of the material, instead of taking the course. As I was reviewing the topics covered in the course, there was a section on “data normalization”. I wasn’t familiar with the term, so I asked my boss what it was. When he told me, my response was “Oh, THAT!”, as he had actually taught me quite a lot about it without using the term.
I passed the challenge exam easily.
A few years later, I got involved in data warehousing, and worked with some amazing team-mates who taught me a LOT about database design, validation, data warehousing, and endless other things.
One of my favourite stories from that time was a discussion where we had identified a hierarchy where A was a child of B. We asked the question about what we should do if we had a B record where no parent A record existed, and got the response: “That can’t happen”.
Hm. Let’s have a look. A day or two later, we asked the question a bit differently: “How do you want us to deal with this set of B records which have no corresponding A record?”
The response was a sheepish: “Oh, yeah...”, followed by a discussion of how the records had been deleted and a discussion about how we could deal with the data.
Just another example of a situation where people break rules because they are in a rush, or are not paying attention, or don’t understand the rules well enough. Far better to deliberately break rules that you understand, since you can document the risk and not be caught flat-footed if/when something goes wrong. I touched on some of this previously (https://www.til-technology.com/post/data-basics-what-is-a-database), but would point out that some technology people use “flexible” tools and models as an excuse to be lazy, rather than as a deliberate choice, particularly since many database products can support both relational and non-relational structures.
Don’t make excuses. If you want to use a particular tool, use it. Just be honest about why you’re using it. If you say: “I want to use X because I’m more comfortable with it”, fine. But don’t pretend that you’re selecting the best tool for the job when you’re really selecting a tool because it’s popular or want to play with it.
It was around this time that I got my first cellphone. It was a brick-sized phone from Clearnet Communications (later bought by Telus). When I told my father about it, he raised an eyebrow skeptically and asked me why I had gotten it. I pointed out the fact that it was useful in case of emergency, and that I could call any time I wanted – remember, this was the 1990’s – but he was not buying that explanation. But then I admitted that it was also a high-tech toy I wanted to play with, at which point he nodded and said: “Ok”.
Now, to business.
KanbanRG now has a basic front-end design that I like, but needs a back-end and database. And since I’m treating this whole project as a learning tool and want to do it in small chunks, I decided to go with a very basic data model to start with.
That said, there is minimal level required, and I decided that I needed to start with at least the following basic tables:
Task
Each post-it represents a task, so this would hold the details of each task, such as the title, details, due date, and so on.
Status
The status is tied to the organization of the Kanban board, and defines the actual columns for the board. In a more sophisticated model, we might want to define mappings between the status and the columns, such as a “WIP” column on the board which includes “Design”, “Development”, and “Testing”. For our initial version, though, we’ll keep it simple.
Project
This is something I find useful. The post-it visual metaphor is very useful, and I find the colour-coding of projects very helpful. (Also, there has rarely been a time for me when I wasn’t involved in multiple projects, and it’s useful to be able to look at them separately)
Interestingly, as I think through the data model, and think about the tool, I keep coming up with additional ideas. For interest and future reference (and to avoid the “mental load” of trying to remember them), I’ll just add them to the board. I may come back to some of them, or maybe not. As an example, I might add a “completion” date for now, then later expand that into more sophisticated reporting on workflow transitions.
In any case, this has also been helpful in learning how to use the phpMyAdmin tool. In times past, I would have built a SQL script for everything, but I already know how to do that – I want to learn something new.
My next steps will be to insert a few records and learn a bit more about how mySQL compares with other databases I have worked with.
Cheers!
Comments