Mysql Naming Convention

Garth Hill garth at
Wed Apr 19 11:23:40 MDT 2006

>Would you name an array "employee" because it is a single reference? 
>that would be confusing: containers should be pluralized.

Actually, yes, I would.  Containers shouldn't be pluralized. I mean, unless you have more than one container.  The definition of a container is one thing that holds other things.  It is singular.  You could go so far as to call it "employee_list" or "employee_set" or whatever.  You don't have some flocks of seagulls.  There is only one Flock of Seagulls..

> That's so confused I don't know where to start...

I believe the word you seek is "confusing."  You are confused.  His logic is confusing.  I mean, since this is a semantic argument and all.

> Although it is occasionally useful to think of tables as type definitions, because of the nature of SQL it is most often more useful to think of them as sets.  Hence the collection analogy.

Care to elaborate on this?  To me, the (record) set is the result of a query.  The table definition fits the idea of a class definition much better.  No one that I know would name a class "Employees," so why name a table that?  The table contains the definition of a record.

> The one thing I would suggest is that you be consistent. That's the only place where I've ever really run into trouble.

What's consistent about using pluralized table names?  Plurals aren't consistent.  If I have a table of type index, is it indexes or indices?  I don't think the "consistent" argument is enough.  The argument I would make above all else is simplicity.  I've spent years sifting through unnecessarily complex code.  The increased complexity of pluralizing table names just doesn't pay off.  No one will look at a table named "employee" and think there can be only one.  The nature of a table is that it has rows (plural).  The nature of a collection is that it has members.  Even if it has zero or one members, it is still a collection.  I've actually run into cases in code where I have had a collection of collections.  So, would I take several "employees" collections and name them "employeeses" ?  All things being equal, the simplest way should prevail.  

Let me give an example.  Say you have two tables, one named employee and one named job.  Say you want to join them.  Here's a nice abstraction (in Perl):

# both tables have an employee_id field
my $table = "employee";
my $join_table = "job";
my $query = "SELECT * FROM $table LEFT JOIN $join_table USING ($table_id)";

Now I've created a nice abstraction.  If I had plurals, I'd either have to have some sort of gimmicky plural translator, or hard code it.  Both of those solutions are less desirable (added complexity without any benefit).

I used to think like the pluralizers.  It made sense until I changed my ways.  I'm not afraid to change my ways again.  But for now, this is simply a better way to do it.  Ed Felt suggested that advanced database theory supports singularization anyhow.  Does it really have to be such a religious argument?  


Everything should be made as simple as possible, but not simpler.
-Albert Einstein

More information about the PLUG mailing list