Earlier quoted context omitted.
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…
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…
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.