Wow... good stuff here!
I agree with Joel re: pluralization; I find it is almost always utilized inconsistently in a design. Some tables will be pluralized, while others will not. This lack of consistency quickly leads to frustration in coding. My design refrains from pluralization. (note: I really liked Joel's take that "Table names should describe what is represented by a single row"! I'm stealing that one for future arguments
In naming I use a "modified" Pascal case; by "modified" I mean I use underscores to separate upper case characters within a name. An example would be a column for CPU SKUs. Since both words are all-upper case, the column name would be CPU_SKU, rather than CPUSKU or cpuSKU or CpuSku, etc. "True" Pascal case is supposed to avoid underscores, period... but I have found this particular exception to be beneficial. An example of one of my typical table names: OrgHierarchy. (Note: I do a significant amount of development in Oracle and DB2, both of which have different limitations on naming conventions. Oracle stores all table names in upper case, thus the use of underscores all over the place in an Oracle environment)
There are a couple of places where I consistently use underscores in object names: DRI, Stored Procedures, and User Defined Functions (UDF). I use the following naming convention in DRI: FK_childtable_parenttable; PK_tablename_column(s). For stored procedures, usp_ for "generic" procedures, rpt_ for procedures used in reporting, adm_ for administrative procedures, etc. The pattern is a lower case three-character acronym, followed by an underscore, then a descriptive name for the procedure. ALL of my UDFs are prefixed by ufn_
I have seen a lot of designs that use a prefix for Views; I am not a fan of this, as I use views to obscure underlying table architecture from users. I have not found the view prefix useful in coding either, as I always develop procedures, functions, etc. using the most selective statements possible; which means accessing the tables themselves. Views typically contain references to columns unnecessary to the query I am writing... which is simply inefficient.
Names should be descriptive, but not ridiculously long. A balance must be struck. In many instances, that balance is achieved via acronyms. THIS, I have found, is a major-league nightmare in design!! The problem again is consistency, or lack thereof. This is why a DOCUMENTED library of acceptable acronyms is crucial to any design. Example: Date = DT, Organization = Org, Server = Svr, etc. Deviation from the documented acronyms is NOT TOLERATED!
(Note: one gripe I have about use of acronyms is they go too far. Some words that don't need to be shortened are
shortened. Best example = DATE. Changing DATE to DT drops a whole two letters... whoop-dee-doo! That is unnecessary IMO. Acronyms should be used sparingly, and only where there is a real benefit).
Another method I have seen used to keep object names short is by dropping non-leading vowels from the object name. Using my OrgHierarchy example from before, the name becomes OrgHrchry. I have found this naming convention to be fairly solid, again, as long as it is used consistently
. (starting to see a pattern here?)
Well there's my two cents