Entity Naming Conventions
It seems as though as software developers mature they develop consistency in their approach to just about every aspect of their work, regardless if there is a good reason for adopting a particular practice or not.
For instance, in data modeling I developed the habit of always naming my tables in the plural - Employees instead of Employee, and such. There's no reason for this convention, other than perhaps I copied what I saw from the Northwind database.
But it's important to question these practices from time to time, and after over seven years of doing things the same way I have decided to make a change. And for the second time now (see my post The Importance of a Logical Data Model), it was a colleague: Steve Dempsey who initiated the change. So why would one opt for singular names over plural ones?
Developers might chose singular names because they are shorter and require less typing, but this argument never held for me because of tools like intellisense and code generation (not to mention touch typing). But Steve is extremely adamant about singular names for a different reason: because of relationship readability.
For instance, in Sharepoint, workflows relate to events. Specifically, a workflow (singular) is initiated by one and only one event, and an event (singular) can initiate multiple workflows, as is expressed below:
The objective of modeling is thus to express the relationship of a single entity (a workflow, an event, or whatever) to zero or one or many of another entity. So why not just name your entities appropriately in the first place: by making them singular?
Of course now the problem is getting an old dog to remember his new trick. Or is it tricks?
---
note: I am now double posting my blog entries, this post is also available on Blogspot.
7 Comments
Leave a comment
0 TrackBacks
Listed below are links to blogs that reference this entry: Entity Naming Conventions.
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/425
Lee,
I see where you're coming from here, but I'm going to have to disagree with you.
Logically, I think that you're correct, when modeling the relationships, it does make more sense for the entity's to be singular. But that's not the only way to look at a database. For example, the Workflow table in your example above is a collection of Workflow entities. Therefore the table itself should be called Workflows.
I try to name my tables the plural of the entity that they contain.
This is all just my opinion, but since I do Rails development, it's a good opinion to have. By naming the tables plural, I'm following the Rails convention and saving myself unnecessary configuration.
I originally started my career learning from a DBA who told me that singular table names were better. For a while I just went with this without really worrying about it, and truth be told it isn't really that big a deal. Well, that is until frameworks like Rails come along that use plural names and if you "just flow with it" everything is much simpler, as you don't need to override the defaults everywhere. Then, if you think about it some more, what is a table? It is a relation, based upon mathematical set theory. A set contains items, not item. So, shouldn't a table, which is a relation and thus a set, be named in the plural? I think it flows better, as in "the products table" versus "the product table." At any rate, I doubt anyone who does Rails development is going to give up the plural naming conventions and the benefits it brings anytime soon. If it's not Rails, I don't care so much, though I still think you have a set of items, not item.
I'm with Lee on this one. The reason I name them singular is because I like to make my model objects match my table names the best I can. Sure I could just strip off the 's' for my model objects but what do I do with irregular plurals. How does Ruby handle this? For example if I have a table that contains "criterion" do I name it "criterions" or "criteria"? How about "person" which one do I choose "people"/"persons"?
Rails tries to be smart about pluralization, so your table would be people not persons. Don't know if it knows about criteria vs. criterions. I think it is just some lookup table in some Ruby class somewhere that maps singular to plural but not really sure. In any case, you can always override the defaults. You'll just do more typing. :-)
Also, your model objects are like the individual rows of a relation/table. So yes, the model objects should be singular as they represent a single row not a bunch of rows. I assume you say someting like "the person with id 25" versus "the people with id 25" when you talk about individual rows in a table. Otherwise can't help you on that one. :-)
Here's a tool that shows you how ruby pluralizes words
http://nubyonrails.com/tools/pluralize
person -> people
sheep -> sheep
dog -> dogs
child -> children
etc...
I have never followed a convention when naming tables but it's usually easier to think of a table in terms of the "things" -- with an s -- that it contains. I see your point with "Workflow is initiate by WorkflowEvent," although, you can also say that "Workflows are initiate by WorkflowEvents."
Also, take a read at http://www.dbazine.com/db2/db2-disarticles/gulutzan5 (search for the word "plural"). Also, you probably notice that all the Oracle system tables are plural. Not that I think Oracle dictate what is good practice, but they are a big name.
Wow, it's interesting to see more people with the same opinion I've always had...plural, all the way. Sometimes there's cross-reference tables that I got into the habit of suffixing with "Xref" or something because there wasn't a good plural or singular form for them. However, in general, I agree with everyone else in that in the terms of a database, tables are "sets" of "items". I don't like it when people try to relate modeling with database design, they are two different things. And yes, when I model, the entities are shown in singular form because that's how "developers" view things in a model. The model represents the relationships between one item of the set from the database.