Aye, I agree with Eddie, can't stand these daft prefixes people get taught at university/polly.
Plural/Singular it doesn't really matter that much, as long as it scans well. Closer you get to natural english the better.
Steve's point about object prefix is absolutely spot on. When you get developers who insist on insert_something, get_something, add_something else its a pain in the jacksy.
They say 'oh but we know its insertx' but is it? it might be 'addx' or 'newx' or gok whatever someone was thinking at the time.
When you need to review the code you mind numbingly scroll up and down 100's of get_x procs. The whole verb_Object construct is just not fun. Object_verb is so much more usable.
Another thing that gets me is when developers assume that the column is always a part of the table, and you always reference it as such.
eg
create table SendMoney(from, to, reason, time)
create table DispatchRider(from, to, reason, time)
So now from can mean several things. of course you wouldn't use From anyway, would you. What with it being a reserved word and all.
I vote thumbs down on prefixes. I am now dealing with 400+ tables that all begin with TBL_XX_tablename, where XX is the initials of the guy who created it. The idea is if you have any questions about the table, you can wander over to the Creator's cube and ask him (we have a rich oral tradition here). Besides, if you can't tell its a table from reading the code, perhaps you should be in IT management...
I do practice the object-verb naming convention. If you have a stored proc that adds a customer, call it CustomerAdd. If you do it the otherway around, you have a bunch of procs that all line up in the treeview like
AddCustomer
AddThat
AddThis
when what you want is
CustomerAdd
CustomerDelete
CustomerUpdate.
London, sign me up if you'd like a DBA with 3 decades of experience who loves to sip a pint and watch football at the corner pub.
Hi EM,
One of the issues noted with prefixes is that the type of object can actually be changed. For instance, you might have a table named "tSales" or even "t_Sales" to use your recommendation. What happens when you change "t_Sales" to a View? You now have to change the name to "vw_Sales" on the server, and you have to change all client code that used to query the "t_Sales" table.
If the justification for using prefixes like "t_" and "vw_", etc., is to make it easier on the eyes in Enterprise Manager, this should not be a problem in SQL 2005. You can prefix all your objects with a schema (other than "dbo.") in SQL 2005, so all your "Sales"-related tables (for instance) will group together nicely (and separately from "dbo.") in SSMS without the need for redundant prefixes in your naming convention.
To use your example, you could group all the Sales-related tables into a "Sales" schema on SQL 2005:
Sales.SalesSales.HistorySales.CategoriesSales.RepsSales.Contacts
Same goes for SP's and UDF's. You can use the simple "ObjectAction" naming convention and assign them to the proper respective schemas.
No underscores for me, either. Fat fingers.
"If it was hard to write, it should be hard to read, and even harder to maintain."
A number of people have mentioned singular & plural when naming a table, as Mr.Celko said - it's a set, hence plural makes sense.
To be slightly obtuse here, use of t or v or pk & fk in naming is useful to someone such as myself who has moved between many systems. These simple conventions shorten the amount of time it takes to get aquainted with a new system. Purity of design versus practicality is something you should ask the guy paying you about, he will always opt for the cheapest pragmatic solution. So why don't you all try that approach.
