Mysql Naming Convention

[C. Ed Felt]

   Jonathan Ellis wrote:

On Tue, 18 Apr 2006 15:14:10 -0600, "kirk" [1]<kirk at emstraffic.com> said:


I was wondering if there is a mysql naming convention for tables and
columns.


Table names should be plural.
Column names should be singular.

(/bites tongue to avoid reacting to someone using "mysql" when he means
"database."  Although I suppose it's good not to confuse the two. :)

-J


   In my upper level Computer Science Database Theory course we used two
   text books: big fat, ugly ones.  Both used singular names for table
   names.  It appears that the reasoning was because the table name
   itself really represents each singular "entity" and there are just
   multiple rows of them.  The table name represents a definition, not
   necessarily the actual things in the table.  I don't remember any hard
   rules concerning the Structured Query Language entity (what we are
   calling "table" here) with regard to implementation of plurality or
   singularity in name.  In the relational database diagrams, however, I
   noticed that the name of the entity with it's attendant properties was
   always singular.  If you think about it, when you "map out" a database
   on paper, you don't write "users" and then the user attributes
   (columns) with plural names.  When forming an ER diagram, the entities
   (maps to "tables") are usually created with singular names, probably
   since in the real world you are defining "a user" not a "users".  If
   we map ER or any other type of database schema to a database, it
   probably makes more sense to stick to the singular naming convention,
   if you want to follow academias way of doing things.
   In fact, usually you don't see plural column names ("attributes" in an
   ER diagram) as well, unless the attribute is itself plural.  For
   instance, a CSV field of email addresses might be called "emails",
   since that one attribute represents several email addresses.  But,
   this is often bad design, as you should usually export multiple values
   to a separate table and relate them back to the "user" with a foreign
   key.
   Personally, I don't think it matters.  But I hope I have shed some
   light on why database tables and the charts that describe them usually
   have singular names, (at least among those who have studied database
   theory).  Databases can function just fine with whatever name you
   please, so long as you understand your definition.
   That's just my 2 cents on db theory.  "Yawn"
   For a good definition of ER diagram check out:
   [2]http://databases.about.com/cs/specificproducts/g/er.htm
   This web site has some good info as well:
   [3]http://db.grussell.org/
   Or buy some mind numbing db theory books.
   -Ed Felt

References

   1. mailto:kirk at emstraffic.com
   2. http://databases.about.com/cs/specificproducts/g/er.htm
   3. http://db.grussell.org/