Naming Conventions for Data Objects

January 25, 2009

One of the things that was at once striking to me about David H’s description of the Ruby on Rails recipe, in the book Agile Development with Rails, was his headfirst launch into the data object naming conventions. They were as follows (this is not complete. For a more complete list, see : http://rails.raaum.org/database-conventions.html ) :

1) Database table names are always to be plural – This reminds me of a project a number of years ago, when the database was being reorganized. Well, they had decided to name everything in the singular. Their thinking was, it is obvious that a table named USER would contain users, a table named ORDER would contain orders, and a table named LANGUAGE would contain languages. It was soon discovered, however, that all of these were reserved words in the RDBMS system we were switching to. The solution was to add a character at the end of the name. So, ORDER became ORDERR and USER became USERR, and so on. The simplicity of just using plural for the table names struck me as something to lean towards in most RDBMS environments.

2) Primary Identity Fields will be named id. I’ve seen many cases where the identity field is named like a foreign key would be. That has advantages, like when the field names are matched exactly, as some tools will do. But  there is nothing wrong with just “id” for the field name, and it is clear what this means.

3) Foreign Key fields will be named (singular table name ) + “_” + “id”

At a certain point, it becomes clear that the rules are in place to assist automatic generation of various pieces of the Rails framework. By simplifying the components and requiring them to adhere to strict naming rules, the framework is able to maximize its power while minimizing complexity. The human user of the framework is admonished to conform to strict guidelines, to enjoy the large benefit.

  These “strict guidelines” (there’s an oxymoron for you), are in support of the concept of favoring “convention over configuration.”  By clearly stating the assumptions and defaults of the underlying framework, the designers have eliminated the need for configuration files which would spell out the exact same details.  Most software development teams would opt to leave the defaults in the first place, making all of the configuration work basically wasted effort.  By adopting convention, and eliminating a large chunk of configuration time, a real quantifiable savings can be immediately realized.

Often, I am lamenting the lost opportunities in computing systems, for real accommodation of the user. I find myself in situations where I have to repeat my phone number to computer systems on the phone, when a network of connected systems should “remember” my phone number, and even pass it on to the agent at the destination of my call. All of that made even more laughable given the fact that we do not block caller id, so the called party has access to my phone number by default, and should not have to ask for it in the first place.  It should simply ask if the number I am calling from is the number associated with the account.

  I was installing a printer on my computer, and operating systems said it recognized a Networked HP 2610 and asked if I would like to use it. I said yes, or clicked yes, as the case may be. Then, on the next screen, I was asked to select a driver. And not just from HP drivers, but from a large assortment of possibilities. HP wasn’t even the default.

So, it leads me to think that perhaps, as I have seen before, there was simply not enough time to address all the issues at the end of the line. The software had to be shipped and besides, we have “online updates” now anyway, so it doesn’t have to be 100%. The engineers probably wanted to take care of these last details, but were pulled off onto another project, and a new team was brought in for support and post release development. Did they plan for this from the beginning? The project managers, I mean. Or did time escape them, as it does so many of us?

Is it possible that they spent a lot of time at the beginning of the project, trying to sort out naming conventions for their data objects, or untangling legacy integrations?  Or editing configuration files for frameworks?  Or, automating things a little bit, by generating the configuration files?  (Even with automation, these things take time to do).  Is it possible that the manager, not being able to read code, did not understand the significance of the efforts under the hood, and was anxious for results he/she could “see”, and cut these efforts short?  Is it possible that with some of the up front efforts out of the way, the underlying engine of the project basically together, that the focus could be returned to the customer, and better managing workflow related tasks?

I, for one, would join the chorus of those who point out the significance of the approach used by David H. in the Rails framework, rather than the specific language he utilized.  That said, isn’t the language itself a convention, and the act of using a different language, a sort of configuration?  Food for thought.

Advertisements