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?
--
Garth
Everything should be made as simple as possible, but not simpler.
-Albert Einstein
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
