[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”)