Using plurals in database and models
Posted: Sun Oct 17, 2010 10:51 am
I don't quite get the convention of pluralizing database table names.
Is this a convention that has carried over from Ruby on Rails (and continued with projects like CakePHP, Symfony) or did it stem from something else?
I name my tables in the singular. I have a "user" table, and an "article" table, etc.
My reasoning: a table is, by nature, a collection. So I consider it an "article table" just like you might have an "article list" or "article array" in your code. You also use an "article class" even though we all know that one class is instantiated by many objects. "Class" is a word that means a set of things sharing common properties, so it's not really semantically far from the notion of a table. Yet, by using the singular for class names, we are using a convention that simplifies things. We don't need two separate strings, one for the class and one for instances. Similarly, it's easier to have one string that applies both to table rows and to the tables themselves.
Okay, so perhaps it sounds better? Or it sounds more "human". Not a good enough reason. To me, a method called getAllArticles() sounds just as good as getEveryArticle() or getArticleList(). My point is that sounding better can be achieved without pluralizing things.
And yes, people seem to go through a lot of trouble. I almost fell off my chair when I saw CakePHP's "Inflector". It's a class that deals with pluralizing words, among other word transformations.
It's 600 lines just to deal with this silly convention! Take about jumping through hoops. It uses a bunch of regular expressions, and then big lists of exceptions to the rules, in an attempt to cover everything. So Person becomes People, Man becomes Men, etc.
Here's an excerpt from the class. (see the whole thing. but put your coffee down first)
The guys at CakePHP have thought of everything. I can imagine it now... "CREATE TABLE oxen ..." and CakePHP has your back!
Conclusion: when a convention requires you to write and maintain a fickle and language-dependent 600-line class, it's not a good convention.
Is this a convention that has carried over from Ruby on Rails (and continued with projects like CakePHP, Symfony) or did it stem from something else?
I name my tables in the singular. I have a "user" table, and an "article" table, etc.
My reasoning: a table is, by nature, a collection. So I consider it an "article table" just like you might have an "article list" or "article array" in your code. You also use an "article class" even though we all know that one class is instantiated by many objects. "Class" is a word that means a set of things sharing common properties, so it's not really semantically far from the notion of a table. Yet, by using the singular for class names, we are using a convention that simplifies things. We don't need two separate strings, one for the class and one for instances. Similarly, it's easier to have one string that applies both to table rows and to the tables themselves.
Okay, so perhaps it sounds better? Or it sounds more "human". Not a good enough reason. To me, a method called getAllArticles() sounds just as good as getEveryArticle() or getArticleList(). My point is that sounding better can be achieved without pluralizing things.
And yes, people seem to go through a lot of trouble. I almost fell off my chair when I saw CakePHP's "Inflector". It's a class that deals with pluralizing words, among other word transformations.
It's 600 lines just to deal with this silly convention! Take about jumping through hoops. It uses a bunch of regular expressions, and then big lists of exceptions to the rules, in an attempt to cover everything. So Person becomes People, Man becomes Men, etc.
Here's an excerpt from the class. (see the whole thing. but put your coffee down first)
Code: Select all
var $_plural = array(
42 'rules' => array(
43 '/(s)tatus$/i' => '\1\2tatuses',
44 '/(quiz)$/i' => '\1zes',
45 '/^(ox)$/i' => '\1\2en',
46 '/([m|l])ouse$/i' => '\1ice',
Conclusion: when a convention requires you to write and maintain a fickle and language-dependent 600-line class, it's not a good convention.