• What a can of worms.  For what it's worth here's another opinion.  Remember it's worth what you paid for it:

    Prefixes - as a general rule I avoid them like the plague unless they server a very specific and limited purpose.

    Tables - no to any prefix unless it's an enterprise wide database and then the prefix should be a "department" name or mnemoninc (hr, sls, mkt, eng, prd).  Prefixing a table with t is the same idea the author discourages when refering to data types in column names.  After all isn't a table the data type for a table?  Tables should be singular nouns.  If a table of Employee records is plural (Employees) then then the follow on logic is that the wrapper CRUD procedures would be CreateEmployees, ReadEmployees, UpdateEmployees and DeleteEmployees.  What if I only want one?  The name may make me wonder if it only creates multiples.

    Views - one of the two places where I really like adding a type identifier (suffix) of _v or _vw.  Views are special case virtual tables and updateability rules will vary.  If I'm messing with a view in procedural code I want something that smacks me on the head to let me know I'm working with one. 

    Procedures - See rule number.  In a moderately complex database you would end up with all Employee related procedures scattered all over the browser window.  Change to a suffix and magic happens because you then end up with Employee_get, Employee_ins, Employee_upd and Employee_upd.  Not really rocket science to find or figur out what those do.

    Functions - the other place I like the type identifier and this time it's (gasp) a prefix (ufn_).  This is to let me know it's a user function.  Again this one smacks me on the head and lets me know I'm working with a user functoin and not a built in one.  ufn_Split(), ufn_LastDayOfMonth(), ufn_ZeroPad().

    Relationships - I head to the OO world here with ChildTable_has_ParentTable.  It really helps out.

    Indexs/Keys - Primary: PK_TableName or TableName_PK; Unique Key: UK or AK and TableName -- If I've got more than one I reevaluate my database design.  Foreign Key (index) FK and the ReferencedTableName.  Wheter you use a prefix or suffix is not relevant to me as I don't "code" against them -- just be consistent.

    One place where the author and I do agree is on the need for being consistent.  I hate to alias anything that's used by another program (columns and parameters) so just don't go there.

    And remember; opinions are like aXXholes, everyone has one and they're all full of it. 

     

     

    --Paul Hunter