WHEN writers get desperate, they can always fall back on the “unrelated-work-of-art” ploy. What you do is take some book that you’ve been reading and write about how it relates to the real topic. The goal is to say the most trite and obvious things that you can, but make it sound profound by relating these truisms to some other work. This ploy works best when 1) the other book is completely unrelated to the real topic, 2) you can count on most of the audience not having actually read the unrelated work, and 3) the unrelated work is sufficiently esoteric and famous that it makes you look good for having read it.
Okay, so I’ve been reading The Structure of Scientific Revolutions by Thomas Kuhn. Kuhn has a lot to answer for, as he’s the person responsible for the current mania for the word “paradigm.” Prior to The Structure of Scientific Revolutions, “paradigm” just meant the format for conjugating verbs. Now the word means… well, practically anything.
One of the topics that Kuhn discusses is how one way of thinking about a problem in the scientific community gives way to another way of thinking about the problem. Kuhn suggests that even the problems change during a scientific revolution: Some problems are simply written out of the book and new ones are written in. It made me think about the changes I’ve seen in programming style.
I was around for the battle over structured programming. On one side were the “you do whatever is necessary” programmers, and on the other side were the “GoTo is evil” proponents. For awhile there was at least the pretense of a middle ground—“You can use a GoTo if you absolutely need to.” Nowadays, unstructured programming is held in such low esteem that the mere presence of the On Error GoTo statement in VBA is considered an example of what an unsatisfactory language it is. To suggest that you’d need a GoTo statement for anything is evidence that you aren’t really a programmer at all.
While there was a long battle over structured programming, the triumph of object-oriented programming happened without any pitched battles. Looking back, it seems that OOP was always regarded as the more sophisticated programming methodology. All that held it back, it seems, was developers’ lack of sophistication and inefficient implementations. It’s gotten to the point that non-OOP programmers are regarded as “just not OOP programmers yet.”
Certainly, I’ve moved from being a structured programmer (I was always on the side of the light) to being an object-oriented developer. But I started as a relational database designer and developer. I’ve always firmly believed that if you get the database design right, everything else is easy. In fact, I believe that if the database design isn’t right, bad things will happen to good programmers.
Which leads me to a discussion that I was involved in on a recent project. In the data model for this application, we had a classic supertype/subtype problem: We had two potential entities that shared a large number of fields. I felt that we should have two tables because we had two entities.
The other members of the team felt that we had only one entity but that it was in two different states. As a result, they recommended that we have one table with two foreign keys. One foreign key would tie to the tables that were relevant to one state, and the other foreign key would tie to the tables that were relevant to the other state. My concern was that it was possible in the data model for both foreign keys to be filled in, putting the entity in both states simultaneously—an impossible situation. My team members responded that the code in the object (or objects) that managed the table would ensure that the two foreign keys were never filled in at the same time. Their feeling was that transferring records between the two tables in my design was just too inefficient and wouldn’t scale well.
I saw their point, but I was horrified. I simply couldn’t imagine putting the responsibility for maintaining data integrity in code when you could put it in the table design instead. My more OOP-oriented team members didn’t have a problem with this. They couldn’t understand why I’d advocate a design that was so inherently unscalable. We’re still working on the problem. In the meantime, I’ve found myself in a new paradigm—processing efficiency beats out relational integrity.
Next month: Jacqueline Susann’s Shadow of the Dolls and relational database design.