| As with any style guide, many things are subjective, and the only correct answer is the one that your team applies consistently, whatever that may be. Overall, these look like a great set of standards to follow. A few items that I think deserve additional attention: > Use a collective name or, less ideally, a plural form. For example (in order of preference) staff and employees. I fully agree with using plural names. Plural makes a lot of sense IMO because tables contain multiple things. An employees table contains many employees. However, I disagree with using the collective name. There is too much ambiguity: the collective name doesn't always exist, doesn't always mean the exact same thing, and there are often multiple options for the collective term. Simply converting it to plural by appending an s (if possible) makes things more consistent and easier to quickly see, and can furthermore help with things like automatically naming tables / deducing table names. Often times code exists that represents a single row in a table (e.g. we might have an Employee class that represents a single employee). Singular here makes sense to me because it represents a single row. To then find the table corresponding to this class (or vis-versa), it's simply a matter of pluralizing. If our table was instead "staff", this would be harder to see at a glance. I'm curious why they advocate collective names--having trouble thinking of any advantages to this. Does anyone have any arguments in favor of collective names? > Where possible avoid simply using id as the primary identifier for the table. This is one of the biggest things you can do for SQL readablitiy IMHO. It's so much easier to quickly see what's going on when columns aren't simply named "id". If I see a column called "userID", I can quickly figure out that it's a userID with much less context than I would need if all I saw was ID. One additional rule I would add, and this is perhaps a bit controversial: always declare columns as NOT NULL if possible, using a sane "empty default value" such as an empty string or 0. If I wanted to find all users without a name, it's much easier to do "SELECT * FROM users WHERE name = ''". This won't match NULLs--if we don't declare NOT NULL, then we must do "SELECT * FROM users WHERE name='' OR NAME IS NULL". Easy to forget this--better to have the extra safety of NOT NULL to prevent mistakes like this. A good rule of thumb IMO is "declare columns as NOT NULL unless you specifically need to allow null". |