Hacker News Reader

Comment by jmnicolas | Hacker News Reader

"Use a collective name or, less ideally, a plural form. For example (in order of preference) staff and employees."

This goes contrary to what I was taught : use singular form. When I model my databases I think in those terms : employee works for 1 to n company, company has 0 to n employee. Since it's a "many to many" relationship you need a third table (entity really) which you could call "working_with". The columns are id_employee and id_company.

This is the basis of the Merise method, but I don't think it's available in English. It makes modeling databases really easy.

View on HN

I would suggest a different approach: Prefer either the plural or singular form, depending on which your ORM prefers. It may not be pretty from a purely stylistic perspective, but the collective forms have a few specific problems:

- mapping is not intuitive for non-native English speakers (flora, really?!)

- manual table mapping needed for ORM systems

I'd prefer the singular, but ActiveRecord uses the plural, and I'd rather go along with the default, rather than fight and create friction for my team.

EDIT: looking closer, the style guide is great, but the naming conventions are atrocious. I'm reminded of what my Intro to CS TA told us: naming stuff is hard, so try to explain your code. If you have to explain what something is, the explanation should be the name (within reason)

When modelling data it should be the primary concern and not an ORM. Different applications will need access to the same information. ORMs are application specific and therefore should not determine how data is structured.

As for the non-English speakers finding the collective difficult; I can see that. I have not specifically considered their needs whilst compiling the guide. In the case of `flora` I am guessing you're thinking `plant`?

I suppose if you need a style guide for SQL, then you're likely in the business of building databases to be accessed by multiple applications. However, be aware that the majority of applications are initially developed using a database as a data store, alongside opinionated ORM systems that will prefer a specific naming convention (such as plural forms).

Speaking from experience, you can't even expect native speakers to know all the collective forms. Worse, in some cases the collective form may cause confusion if the collective is the singular of a different table (players in a team, teams in a league, doing a fantasy football league app).

Using the plural, your schema would be player -> team -> league. Using your system, it would be team -> league -> sport. Good luck explaining that to a new hire.

No, actually the collective of player isn't team in this case.

Not all players will be on the same team, but they still participate in the league so I disagree with this example terminology shift.

You would end up with a slightly more generalised naming like this in my opinion:

- athletes - teams - leagues

In this particular case there are no suitable collective terms.

This is an interesting idea. I will give it some thought as others have also suggested similar. Perhaps the guide could be relaxed a little to allow singular names.

Someone mentioned that tables can be considered like types - another interesting thought - in which case singular makes sense.

On the other hand it is a collection of something and therefore the collective term applies equally well.

I also use singular for every table and column name. It just makes everything simpler. If I had table of scissors, it would be called `scissor`.

Reply on news.ycombinator.com