Wednesday, July 30, 2014

Doing stuff, tooling around

Phil Factor (which is a phunny name for a database guy, I admit) wrote another good article, called On Managing and Doing Stuff.
The titans of industry that founded the modern age didn’t just sit around sending each other emails (we called them Memos then), but they did stuff. This didn’t often merely involve talking loudly and waving their hands about, but really doing things.
The comments are as interesting. I don't usually read comments on articles, but in this case, they are few, and because they're on a technical site, generally cogent. (Well, try that in, say, an overclocking forum).
The essence of your article I take to be this – education is no substitute for experience.
I agree, but theory is also worthwhile, because it makes experience, at least of a technical nature, more enjoyable. It's satisfying to know, simply put. We can know through experience, of course, but also we can know through understanding, which are not synonymous.

For example, this from SQL expert Joe Celko:
In file systems, each magnetic tape or disk pack was physically and logically separate from the other files in the enterprise. It was the restrictions of those "silos of data" that provided the motivation for developing databases. Enterprises were like a man with a thousand mechanical watches and clocks who then suddenly needs to have them all synchronized and accurate to a micro-second. Oops! Impossible.
Data modeling is related to, but not actually part, of RDBMS. In an ideal world (especially if you are a data modeler or a enterprise level DBA who wants full employment) your entire enterprise would have a single, honking big data model, most of which could be programmed into a database. It leads to the idea that data elements have one, and only one, name and one definition over the entire enterprise or (better) the entire industry (i.e. VIN applies to all automobiles in the world).
At a basic level, we divide tables into those that either model entities or model relationships among those entities. A table cannot do both at once, please. SQL does not have explicit syntax for these concepts, so you have to do it yourself. The way you do this is with a relational key. Yes, you can declare a "table" in SQL without a key at all, in violation of the relational model. This means that you have a file system that happens to be written in SQL. This misses the whole point of RDBMS, and costs you all the advantages we gained from replacing file systems.
In my professional life I've seen many tables without keys, but I hadn't considered until I read this that they fall short of what they should be. When the theory isn't applied, we have a devolved tool. And yet we rush to the next shiny tool, thinking it must be It (or is that IT, ha). And then we spend too many hours in inefficient ways, down the road.