Naming Conventions
-
I have come across a scenario where I have to move a table from an application specific database to a database that is shared by all applications.
Given that it is referenced by several procedures and views the most transparent way of doing this is by replacing the table with a view of the same name pointing at the generic applications database.
In this case a prefix or suffix would be misleading.
End user apps don't make the distinction between views and tables.
-
I like the suggestions in the article, but as suffixes so that items related to the same data fall together in a directory listing. =Marty=
Regards,R Martin Ladner
futureec.com -
I think the important thing is not what the standard is but the fact that there is a standard.
Company A may have a totally different standard than Company B but provided everyone in Company A buys into their standard that is all that matters
-
...and corresponded with two of the individual members of that ISO board. They informed me that their ISO was intended for Metadata only and not for database objects.... <insert sound of rousing applause cascading to a standing ovation here>
Well done, Antares!
And good luck with some form of meaningful naming of foreign keys when it comes to the miserable 32 character limit that Oracle still has on database objects.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
A good read, and I agree with some things, such as CAPS to define word breaks. What I don't agree with; and seems as if I am not alone here, is prefixes such as 't' for table. What do I need that for? Never found a use for it myself and sorting objects becomes a real pain.
Also another thing. People tend to include a 'ID' column in every table and it is often a waste of space; and clustered index if it is defined that way. I prefer natural keys. The exception of course is things like CustomerID, StatusID, ect.
In the examples above I much prefer the method or convention that I used here rather than calling a StatusID simply ID. When writing a complex stored procedure it is really nice to see that I am dealing with WHERE CustomerID = 'whatever' AND StatusID IN (SELECT StatusID FROM L_Status WHERE Active = 1)
Another comment here. I Usually HATE Underscores. I do use them in table names from time to time as it makes it easier to ready. Lookup tables for example all start with L_ SO, The Status table would be L_Status; the First Column is StatusID
To that end I have more or less changed to using an Underscore in all table names. The first letter is used to group by table type / class / whatever you want to call it. As an example all of my tables having Customer data will start with C_ while subscritions for a customer may start with S_
Anyway, there is my
2no make it 10 cents.
Jeff
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
-
I too don't like a "t"|"tb[l]" prefix, no least of all because a view can be changed to a table and vice-versa. Column prefixes, of any type, are even worse.
I do like the idea of mixed case with no _s for names (underscores too difficult to type). And of prefixing indexes and constraints with the table name, since it groups them all better in alpha listing of objects.
However, I don't like to include the column name in the index, just "_CI" for clus index and "_IXnn" for non-clus (yes, there is a good argument for not designating the ci in case *it* changes).
Finally, I think "Id" should be used for only an arbitrary number assigned as an id, not any key value, and should be spelled:
Id not
ID
Why is the "d" capitalized??
Btw, "name" is not a reserved keyword, SQL just colors it in the editor.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
-
the table name prefix in front of the column name was created in a place I once worked, an example was a table called Monthly_Rates , the column names were then prefixed with the table name to end up like Monthly_Rates_MonthlyRate int, Monthly_Rates_ChangeDate datetime etc.
then when you qualified queries you ended up with dbo.Monthly_Rates.Monthly_Rates_MonthlyRate ... arrghhhh - yes I know you use an alias but it's an example of an encounter. The same person also liked using prefixes on names to indicate the data type so you ended up with dbo.Monthly_Rates.Monthly_Rates_iMonthlyRate , which had to be changed to multiple chars to handle datetime and decimal so ended up dtChangeDate .. ugh!
If you really want to get a grip on naming work in Binary systems, whole new ball game!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/ -
I liked this article just because I'm interested in how other people name their 'stuff'. Occasionally I will try out a new idea, and this article shared ideas in a quick list. While I agree having a consistent naming convention is generally useful, I think it is also important to be able to tweak a scheme over time in favor of ideas which give better results. So, see what works for other people and maybe give it a try.
Here's my little add-on:
When UDFs (user defined functions) first came out, I prefixed them all with fn_. However, over time, I found it much more useful to use: fs_ (for scalar UDFs) and ft_ (for table UDFs).
It's interesting how many people have posted that they don't like prefixes. I've found them to be very helpful in managing my objects and reading my queries. Different strains for different brains.
- JJ
Eugene, OR, USA
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply