It’s an English literacy thing - we have several non-native English speakers and using only singular avoids making those folks’ lives harder. Besides it’s really nice to autopilot that categoryid is a foreign key to the category table. It also simplifies always plural words… I haven’t yet written CREATETABLE pants but if I ever do there’s zero chance of me creating a pantid.
I tend to use underscores on join tables so table foo_bar would have a fooid and a barid. I have somewhat soured on this approach though since there are a lot of situations where you’ll have two m-m relationships between the same two tables with a different meaning… and having a fixed formula for m-m tables can make things ugly.
If I get to design another greenfield database I’ll probably prefer using underscores for word boundaries in long table names.
It’s an English literacy thing - we have several non-native English speakers and using only singular avoids making those folks’ lives harder. Besides it’s really nice to autopilot that
categoryidis a foreign key to thecategorytable. It also simplifies always plural words… I haven’t yet writtenCREATE TABLE pantsbut if I ever do there’s zero chance of me creating apantid.no underscores either? What are we, apes?
I tend to use underscores on join tables so table
foo_barwould have a fooid and a barid. I have somewhat soured on this approach though since there are a lot of situations where you’ll have two m-m relationships between the same two tables with a different meaning… and having a fixed formula for m-m tables can make things ugly.If I get to design another greenfield database I’ll probably prefer using underscores for word boundaries in long table names.
I always thought they should be singular to be closer to the names we give entities and relations in a entity-relation diagram.
That too, singular table names just makes a lot of stuff more automatic.