The debate about singular/plural naming for relations comes up frequently. In my opinion, it stems from the fact that English has only 2 forms for all the possible grammatical cases. It has only a different form for the singular and plural cases, and thats what people concentrate on. I propose to take a step back.

There are quite some languages that have different forms for the nominative, accussative, dative and genetive case. Lets take Latin and the concept of an unpaid developer (servus).

Servus is nominative singular. Lets make it plural: servi.

  Select from servi...

oh wait, we have a from so we need an ablative plural here. So we get:

  select from servis...

What about updating? Then we need a plural accusative form:

  update servos...

But are we updating the whole collection or just a single record? Then we should probably talk about servum. Et cetera ad infinitum.

This might be a little overstretched.. Why don't we just use the normal form (the style guide talks about natural) of a noun? Good question, that is the singular nominative form. So, why make a special case for plural and ignore al other grammatical concerns?

Ian Mackinnon, is that you? (http://stackoverflow.com/a/3894235/1163893)

Nope, i am not. But good catch, since his comment on SO made me originally see the light. :)

Honestly, if Latin-speakers had invented high-level programming languages (and, especially, languages intended for the kind of use and audience that motivated the design of SQL), they'd probably just include noun declensions as part of the declaration, and then decline the noun properly for the way they were used, rather than settling on single form.

Yes, that's not something we'd do with Latin declensions in a language designed by English speakers, but that isn't really an argument against naming collections with plural nouns in such a language, just because doing what might be natural in a language designed by Latin speakers to resemble Latin doesn't make sense to us.

It makes me curious if you apply the same rule to variable names in (other) programming, when they contain multiple items of a kind (e.g. arrays, lists, sets and so on).

  FrequentCustomerArray

rather than

  FrequentCustomers

? If not, why is that different?

It isn't different. There's a conflict between using the collection as a whole

    map(foo, FrequentCustomers)

and using a member

    foo(FrequentCustomer[0])

Perl has plural / singular inflection :-)

    map foo($_), @FrequentCustomer;

    foo($FrequentCustomer[0]);

I always trying to use singular form. I didn't give it much thought, I just don't like repetition, and all those "-s" are exactly repetition (not even saying about non-trivial things like "man-men", etc). The only place where it bit me every time is table for users. "user" apparently is a reserved word and I can't use it as a table name (without quoting). Otherwise I liked my approach.

I prefer singular; using a plural or collective casts the table as a container of instances, rather than as a relation between attributes.

Object oriented design principles do not effectively translate to relational design

Not to mention with an ORM tool you'll have an Employee object, and probably call your collection employees.

Which is better?

foreach (var employee in staff) {

}

or

foreach (var employee in employees) {

}

Honestly, they both look fine, but they do impart different meanings. "Staff" implies a set of employees dedicated to something like a company or project whereas "employees" could refer to multiple employees in any context.

If you're walking on to a new project, these subtleties make all the difference in understanding what's going on without having to rely on documentation.

In my case, we have anywhere from 3 to 20+ types of employees, and "staff" is the word commonly used to refer to one of those classifications. Certain information requires different levels of protection for some of those classifications. While people can transition between classifications, it's not a very common occurrence, and it only makes handling their information more difficult (and the old classification may apply to the information for a specific period of time after the change, or indefinitely for some types of data).

I basically end up with a "people" table which holds a very small amount of common data and is used in a lot of relationships.

Honestly, the distinctions require a great deal of documentation to fully understand. However, making the data less normalized and a little harder to comprehend also protects new people from making honest mistakes which could lead to legal issues.

> and probably call your collection employees.

Really ? IMHO this is a bad practice : it makes the code les readable and breaks the auto-completion ...

Doesn't break autocomplete in Visual Studio 2015...

What would you call it?

Better is, imho,

  foreach (var e in employees) {
    // ...
  }

because the iteration variable is essentially a placeholder.