Mysql Naming Convention

C. Ed Felt ed at
Wed Apr 19 12:50:18 MDT 2006

Garth Hill wrote:

>> Would you name an array "employee" because it is a single reference? No;
>> 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? 

Thanks for the explanation Garth.  I wasn't sure about academia having 
the better theory.  Research and educational tenets can sometimes miss 
the mark when compared to real world scenarios.  But, I think you've 
made it pretty clear with your examples that perhaps the old guys that 
spend all their time thinking about these issues could be right, (as 
opposed to those mired only in the technical application of Relational 
Data Bases).  This discussion has helped me solidify a previously weak 
opinion on the subject.  I tend to put plural names at the top of 
spreadsheets for items listed in each table and I think I'll continue 
this practice.  But it's hard for me to consider a database table as 
simply a spreadsheet table on steroids and do the same with my database 
definitions.  I feel that the ER diagram with it's singularly named 
entity and attribute definitions maps much more elegantly in both the 
practical and theoretical sense directly to the table and column 
definitions of a Relation Data Base.  I suppose those who enjoy hard 
coding and having to make heads or tails of possible multiple "s" and 
"esses" can stick to the plural naming system.  As one who has spent 
plenty of time in both theory study and practical application, I have to 
agree with Garth.   I think the real issue here is those who see the 
table name as a definition of the entity type (theory) versus those who 
think of the table name as a direct description of the actual contents 
of the table (overly simplified practicality).

Please remember everyone, this is my personal opinion, not to be taken 
personally by anyone, (I hope :-) ).

Some Python to illustrate (much prettier than perl -- but that's a 
different subject ;-) ):
cursor.execute("SELECT * FROM `employee` LIMIT 10;")
employees = cursor.fetchall( )
I now have a tuple of ten employees: a set of data with attributes 
defined by the entity called "employee" not the entities defined by 
"employees".  Definition, not definitions.
Now I can continue to process my data:
for employee in employees:

Maybe we're all just straining at a gnat anyways.  Or just straining at 
an "s". :-)


-Ed Felt

More information about the PLUG mailing list