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:
do_something_with(employee)
Maybe we're all just straining at a gnat anyways. Or just straining at
an "s". :-)
Thanks,
-Ed Felt
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
