The Scoop

As Adrian points out below, this might be more properly titled Data Normalization and CAR.

Like a lot of CAR folks, I got my start working with rows in tables. For a given story or project, you might need one database table or 20, but basically you “designed” the database - if you had that option - with the idea of getting the best results for the story. Queries were saved, mostly, and the data was kept separate since it made sense to have data associated with the project or story you were working on. The result was directories full of standalone tables or database servers with silos of data that had few obvious ways to connect them.

Working with the Web made me change the way I think about data, and for the better. I’ll stipulate upfront that I’ve never been the most organized person on the planet, but once I wrapped my head around the principles of object-oriented design, the implications for CAR folks were profound. It helped that I’ve been using a Web framework built around OOP principles, too, which is yet another reason why you should learn how this stuff works.

Consider a collection of political candidates, something news organizations routinely compile. What you want to know about a candidate can depend upon what office he or she is seeking and when. That usually means that news organizations end up dividing candidates into tables based on geography or office - local candidates versus statewide or national candidates, for example. But when you have separate tables created over time, their columns might change in ways that make it harder to use the entire set of candidate data, in case you want to track candidacies over time and jurisdiction.

Using OOP principles, you might have a Candidate class, which has certain characteristics (name, date of birth, hometown). Election-specific candidate information could be represented by a subclass of Candidate, say CityCandidate. CityCandidate could add additional characteristics that aren’t relevant to candidates for the House or Senate, for example. But the underlying information common to all candidates is kept in the same format, since it is inherited from the original Candidate class. This means that no matter how many types of candidates you have, all of the common data is stored in the same way.

In a similar way, OOP (and data normalization) encourages you to design a database in which objects, rather than rows, are valuable. So when you’re designing that candidates table for the first time, you might not think to make the election itself a separate table linked by a foreign key since you’re probably only concerned with a single election. OOP principles help prod you to make your database design as accommodating as it can be without sacrificing usefulness. So adding additional elections means adding new election objects, not reworking your candidates table (or worse, creating another table that’s similar).

Most of the CAR folks I know who have dabbled with object-oriented programming languages like Python or Ruby initially were fairly lost, and I definitely include myself in that statement. It didn’t make a lot of sense, mostly because it wasn’t the way that we were used to thinking about databases. But once you clear that conceptual hurdle, OOP opens up a whole new world to you and encourages database design that is useful for the current project and beyond.