Over internet you can read a lot about tables naming standards. What I'm interested in is your opinion about using singular vs plural form of table names. E.g. Client vs Clients When looking over internet, you will find opinions 50 to 50 per cent when asking about singular vs plural form. I would like to hear opinion of people here on Ask.
I tend to go with singular, descriptive names. Singular or plural doesn't really bother me that much, but it seems that a table named Balcony makes more sense than one named Balconies. I don't get the point of the extra letters that don't really change the overall description of the entity being stored. That said, generally, no abbreviations unless they're very standard, such as ID for Identity. Camel case most of the time... Pretty much name my database objects by what they do for the business. No "hungarian" crap (in quotes because Hungarians & their culture are fine, "hungarian notation" is an abomination). Mostly though, let's just make it clear. I'm cool with Employees or Employee. I might be OK with Emp. But Emply... oh hell no! I had to deal with a naming standard, focused on Oracle of course, that resulted in Ddltbl for Deductible. Figure out why that might make me crazy. So real words or commonly accpeted abbreviations only please.
With emphasis that this is just my opinion, I prefer using plurals for most tables. It simply seems to fit grammatically and aesthetically better for me, and I tend to mentally think that the singluar form makes more sense for one row of data. While I acknolwedge that is mostly an aesthetic opinion, I do think it is best that each database (or better, each organization) does have onee fixed standard. There is no real advantage to singular over plural, but mixing them together tends to make it harder to remember the table names and can lead to confusion (or at least greater need to look up names0.
My preference is to have something descriptive, **without** a prefix of tbl or t_ etc, and use the plural form as it seems to relate to an object that contains lots of records of the singular. As @timothyawiseman says, grammatically it makes discussion and disabmiguity easier. IE the Clients table holds Client records. All of the Clients are in the Clients table. Select a Client from the Clients table...
Yes, I've been frustrated by this myself. I think that the most important rule is consistency. If you always use plural, use it across the board everywhere. That way, you don't have to wonder if a table name has an "s" at the end or not. That's not easy to do, to me for instance the table for employees seems to sound better to be named "Employee," but a table for clients should be plural. Personally, I tend to make the table singular unless it sounds completly wrong. For example, I don't think a table for bills should be called "bill." 'Makes me think of Kill Bill. :-D edit: for bad English
Strange..... but I prefer singular table names. I think this stems from when I learned about data modelling and so I would model a 'Client' as an entity in an ER diagram. Then when moving from the logical model to the physical, the names would just stick. I understand the logical reasoning given by @TimothyAWiseman and @fatherjack, but its just preference!
Very good answers so far. My five cents: Logically, I think singularis is preferred, perhaps because I always do object oriented development and objects should be singularis, unless they are collections when pluralis would work fine. But in real life, I find myself often creating tables with pluralis names anyway, much to my own disliking. So I'm unfortunately not always consequent, and my libido seems to want pluralis. Prefixes and suffixes should of course be banned. However, if they are already in a database, they are. I have inherited two databases which are tightly connected - an E-commerce app and a catalogue app. Initially the catalogue tables were copied to the E-commerce db once per week. The database designers of these two apps thought it was a good idea to use _different_ prefixes for the two databases, to in the E-commerce DB know which is which. Therefore, in the same database we had: tbl\_user - users for the E-commerce app tblUser - users for the catalogue app Oh.. And of course, the tbl\_ prefix for tables is matched with sp\_ prefix for stored procedures... Etc. Bad, bad, bad naming conventions. But that's how it is, and we probably won't rewrite all the application code to get this sorted out. So even if I very much dislike the naming conventions in some databases, I think we'll stick to them for those specific databases, and when creating something new, there will be perfect names for all objects :)
As I understand it, Joe Celko is a little like Marmite (love it or hate it), but he wrote a book on this sort of thing: [SQL Programming Style] - He also wrote the book on a lot of things, including ISO and ASNI SQL standards. According to him, tables should be plural nouns (I agree) and should not be preceded with "tbl" or anything similar. He goes on to explain all sorts of other "style" principals. While I don't agree with them all, the book is certainly a good way of getting a cleaner guideline put together. I used this as a primer for setting up database programming guidelines at my current job. The main win is really having a standard at all, whether it fits to everyone else's view or not is pretty irrelevant. :
Not that I'm going to say anything that hasn't already been answered, but a few points: 1. Whether you choose singular or plural is up to you. You've already read about many of the reasons that some people pick one over the other; which of these reasons is/are important to you? Whatever they are, at least 100 times more important is that you document your standard, stick to it yourself, and enforce it amongst your team. 2. I prefer plural. Why? Because unless the table will always have exactly one row, it is a table of Employees, not a table of one Employee. Put another way: A table is a set. You have a set of Employees, not a set of Employee. 3. Collective names (e.g. EventLog vs. LogEntries, Calendar vs. Dates) are a great sidestep to this issue, but collective names are not always available (what is a collective alternative to Companies?) or do not always fit logically into an existing data model. Not just talking about table names but also how you refer to these entities in documentation and in spoken conversation. If your employees are referred to in all systems as EmployeeID, and you use Personnel to spare yourself the agony of typing an extra S, what is the key in that table? PersonnelID, or EmployeeID? (Please don't say ID.) Not if you choose PersonnelID to match the table name, you're going to have unintuitive joins like p.PersonnelID = eh.EmployeeID. Personally I prefer the key to have the same name throughout the model when possible, rather than be dependent on the table that it's in. 4. Not sure what you expect to gain here except to confirm that the split is going to be roughly 50/50 here, just like it is in all the other discussions you've reviewed to date (and probably all of the discussions you haven't reviewed, too).