[veonik]

Some of these arguments are a little questionable imo.

"It reads well everywhere else in the SQL query:"

You can alias the table names and have it read well in all places, and this mostly only matters if you are actually writing SQL and not using an ORM directly, which the next point seems to imply you would be using.

"The name of the class you’ll store the data into is singular (User). You therefore have a mismatch, and in ORMs (e.g., Rails) they often automatically pluralize, with the predictable result of seeing tables with names like addresss."

Almost any modern "pluralize" implementation would handle this correctly. Rails would call the table `addresses`.

"Some relations are already plural. Say you have a class called UserFacts that store miscellaneous information about a user, like age and favorite color. What will you call the database table?"

You would call the table user_facts... Am I missing something?

[MrJohz]

I think the point the author is making there is that normally, each row represents a single item, but in this example, a row represents multiple facts. So normally you might have User(name=Bob, pw=**), but here you've got UserFacts(age=93, hair_color=gray). That is, UserFacts is a single instance of an object that happens to be a bundle of facts. So when you come to create the table names and use plurals, you can convert User to users, but UserFacts can't be pluralised again. (user_factses?)

Fwiw, this seems like a pretty contrived example, and I'm struggling to think of a better one. Maybe if you recorded user achievements as a single row for each user, with each achievement being its own column? But in most situations like that it would probably be best to take the extra normalisation step and just have a separate table for all the achievements in the game, that way it's a lot easier to add new ones.

[riwsky]

But if we’re already in SQL pedantry mode, we wouldn’t be storing multiple facts in one row to begin with. “Use singular SQL table names so that using a relational db like a document store is less awkward” is a weird argument.

(The right answer, as others have already pointed out, is “whatever is consistent”)

[TehShrike]

aliases that you have to use frequently are a sign that something in your schema is named inaccurately.

[hooverd]

I'd call it user_facts too, it's an 1:n relationship from users to facts. Maybe `users_facts` if it's an n:m relationship, but frankly I can never come up with good names for many-to-many tables.

[RobAley]

I'd call it users_facts. But that's just me.

[veonik]

There's definitely some ambiguity there, that's a good point.

I'd probably say that users_facts would be a to-many join table between users and facts, like if you had one row per fact and a multiple facts per user though that example doesn't really make sense here (could just have the FK exist in Fact and not need a join table). If UserFacts were stored in a table with multiple facts in one row about a single user, I would probably call that table user_facts.

Would probably also be fine with running across either in any codebase (or even singular table names, for that matter! as long as it's consistent :D )

[zepolen]

user_facts if it's one to many

users_to_facts if it's many to many