Ok there's no way I am prefixing database names with "db", no way I'd prefix column names. But views, functions and procs yes. Tables, well I don't think there's a real need... but if the project requires it, then hey ho. The biggest issues arrise where one or more standards are used within the same database, which does look crud.
GilaMonster (1/25/2010)All I find that prefixing stored procedures does is make it harder to locate them and navigate to them in Object Explorer
If they've all been prefixed with the same "tibble" then the order would be the same with as without. It's only if mixed tibbles are being used where you get issues.
Tables and views are worse. Let's say I have a large table that's been called tblClientTransactions, then, due to volume or new development it becomes necessary to split the table into 2. The standard trick would be to create a view with instead of triggers with the name of the table to present an unchanged interface to any queries that need to see the table as it was (especially if the queries are embedded in the client app). Now I have a view named tblClientTransactions. Hmmmm....
Now that's a clever trick I hadn't though about... but then the dev's would now also need to know which are views with triggers on.... Hmm not something easily seen at a glance of a name.
Personally I do like to know the difference between a view and a table. If it has a table has to be split and a view placed above then the app code should be changed unless the app code uses stored procedures. I don't like app's doing table level stuff... but unfortunatley where I work, this is common place.
At the end of the day each to their own, as long as they follow the design laid out when working in someone else's sand pit.