Return to Answer

1 No, table names should be singular.

While it appears to make sense for the simple selection (select * from Orders) it makes less sense for the OO equivalent (Orders x = new Orders).

A table in a DB is really the set of that entity, it makes more sense once you're using set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

That last line, the actual logic of the join, looks confusing with plural table names.

I'm not sure about always using an alias (as Matt suggests) clears that up.

2 They should be singular as they only hold 1 property.

3 Never.

If the column name is ambiguous (as above where they both have a column called [Key]) the name of the table (or its alias) can distinguish them well enough. You want queries to be quick to type and simple - prefixes add unnecessary complexity.

4 Whatever you want, I'd suggest CapitalCase

There's not one set of absolute guidelines on any of these.

As long as whatever you pick is consistent across the application or DB I don't think it really matters.

My opinions on these are:

1. No, table names should be singular.

While it appears to make sense for the simple selection (select * from Orders) it makes less sense for the OO equivalent (Orders x = new Orders).

A table in a DB is really the set of that entity, it makes more sense once you're using set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

That last line, the actual logic of the join, looks confusing with plural table names.

I'm not sure about always using an alias (as Matt suggests) clears that up.

2. They should be singular as they only hold 1 property

3. Never, if the column name is ambiguous (as above where they both have a column called [Key]) the name of the table (or its alias) can distinguish them well enough. You want queries to be quick to type and simple - prefixes add unnecessary complexity.

4. Whatever you want, I'd suggest CapitalCase

I don't think there's one set of absolute guidelines on any of these.

As long as whatever you pick is consistent across the application or DB I don't think it really matters.

My opinions on these are:

1. No, table names should be singular.

While it appears to make sense for the simple selection (select * from Orders) it makes less sense for the OO equivalent (Orders x = new Orders).

A table in a DB is really the set of that entity, it makes more sense once you're using set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

That last line, the actual logic of the join, looks confusing with plural table names.

I'm not sure about always using an alias (as Matt suggests) clears that up.

2. They should be singular as they only hold 1 property

3. Never, if the column name is ambiguous (as above where they both have a column called [Key]) the name of the table (or its alias) can distinguish them well enough. You want queries to be quick to type and simple - prefixes add unnecessary complexity.

4. Whatever you want, I'd suggest CapitalCase

I don't think there's one set of absolute guidelines on any of these.

As long as whatever you pick is consistent across the application or DB I don't think it really matters.

1 No, table names should be singular.

While it appears to make sense for the simple selection (select * from Orders) it makes less sense for the OO equivalent (Orders x = new Orders).

A table in a DB is really the set of that entity, it makes more sense once you're using set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

That last line, the actual logic of the join, looks confusing with plural table names.

I'm not sure about always using an alias (as Matt suggests) clears that up.

2 They should be singular as they only hold 1 property.

3 Never.

If the column name is ambiguous (as above where they both have a column called [Key]) the name of the table (or its alias) can distinguish them well enough. You want queries to be quick to type and simple - prefixes add unnecessary complexity.

4 Whatever you want, I'd suggest CapitalCase

There's not one set of absolute guidelines on any of these.

As long as whatever you pick is consistent across the application or DB I don't think it really matters.

My opinions on these are:

1. No, table names should be singular.

While it appears to make sense for the simple selection (select * from Orders) it makes less sense for the OO equivalent (Orders x = new Orders).

A table in a DB is really the set of that entity, it makes more sense once you're using set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

That last line, the actual logic of the join, looks confusing with plural table names.

I'm not sure about always using an alias (as Matt suggests) clears that up.

2. They should be singular as they only hold 1 property

3. Never, if the column name is ambiguous (as above where they both have a column called [Key]) the name of the table (or its alias) can distinguish them well enough. You want queries to be quick to type and simple - prefixes add unnecessary complexity.

4. Whatever you want, I'd suggest PascalCase

I don't think there's one set of absolute guidelines on any of these.

As long as whatever you pick is consistent across the application or DB I don't think it really matters.

My opinions on these are:

1. No, table names should be singular.

While it appears to make sense for the simple selection (select * from Orders) it makes less sense for the OO equivalent (Orders x = new Orders).

A table in a DB is really the set of that entity, it makes more sense once you're using set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

That last line, the actual logic of the join, looks confusing with plural table names.

I'm not sure about always using an alias (as Matt suggests) clears that up.

2. They should be singular as they only hold 1 property

3. Never, if the column name is ambiguous (as above where they both have a column called [Key]) the name of the table (or its alias) can distinguish them well enough. You want queries to be quick to type and simple - prefixes add unnecessary complexity.

4. Whatever you want, I'd suggest CapitalCase

I don't think there's one set of absolute guidelines on any of these.

As long as whatever you pick is consistent across the application or DB I don't think it really matters.