Since you're asking about naming, let me give you a piece of advice which will lead to one possible answer to your question:
If you're not sure, just get into the habit of always surrounding object names in [SquareBraces]
, then it doesn't matter too much what you call your objects.
But having said that, it's definitely best to follow a good convention, either the convention common in your workplace, or find another sensible convention to follow (sometimes it seems there are more opinions about naming conventions than there are people coding them!).
My preferences (FWIW) put simply are:
- Table names that reflect the entity that a single row contains, eg,
[Order]
, [OrderLine]
, [Customer]
, etc. To answer your original question, you'll notice that ORDER
is a keyword here, but as soon as you put square braces around it the parser knows it's an object. Works every time, and you don't have to make contrived or redundant names for the table that holds Order records, for example CustomerOrder
.
- Composite table names for many-many linking tables reflect both tables being linked where it makes sense, such as
[Customer_Contact]
, [Product_ProductCategory]
, etc.
- Primary keys are always called simply
[Id]
, regardless which entity it is a primary key for, unless there's a very good technical reason not to, which is rare.
- Foreign keys are named after the table and column of the PK they refer to, eg.
[CustomerId]
.
As to why I name tables in the singular, rather than think of a table as a collection of, say "Customers", I think of it as a repository where objects of the type "Customer" are stored. This works particularly well when using some ORMs (I like Dapper in C#, but it doesn't work so well with some others where pluralism is almost forced), so you'll have to work out what works best for you and what you're most comfortable with.
Good luck!