We'll go no more a' tibbling

Question

We'll go no more a' tibbling

Viewing 15 posts - 31 through 45 (of 77 total)

You must be logged in to reply to this topic. Login to reply

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 1

Steve Jones - Editor (1/25/2010)
Functions are a place where I think I might consider this. Now that we have scalar and table functions, and it might be worth letting a coder know that a particular type of function is being used in code.

Even there, how it's used tells you what it is.

Scalar udf - SELECT dbo.theFunction(@a)

Table-valued udf SELECT * FROM dbo.theFunction(@a)

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Nick H SSC Journeyman Points: 95 More actions · Answer 2

I use it pretty much everywhere, but the single letter kind not three letters.

For tables, a simple 't' in front of it keeps them seperate from system tables and makes the use of reserved works not constantly require [] which I am not a fan of using.

For fields, same issue on reserved words, simply more convenient. It also allows me to multiuse the same column name for different types when required. If you have to add _date or whatever to a field, you are doing the same thing anyway. And well it's nice to get a smaller list by typing 's' in SQL Prompt.

Do I have to use it? Of course not. I don't have to do anything. It works for me and itsn't going to hurt anyone that has to come behind me. They are just as likely to have their own way of doing things that doesn't match me no matter what I do, so why should I limit myself.

BTW, whoever it was that said any database having hungarian in a database must be from access. News flash: yours stinks too.

Anyway, like most things, use whatever works for you and helps to get the job done. The reality is that I've yet to come into a job in my last 15 years of being a contractor where database dictionary rules of any kind existed. I just adapt to whatever is in use - and I think this is key - whatever you do needs to be consistent. There's nothing worse than coming into source code or database to find five different ways of doing things. That's the bottom line to me. Anyone professing there is a right or wrong here has bigger issues.

There are few hard and fast rules that you are allowed to live by and what few there are someone is going to argue with. Keep it consistent and it won't really matter.

Tom Garth SSCertifiable Points: 6193 More actions · Answer 3

I typically have never seen the need for prefixing the object names in any database that I developed with the exception of some field names, and I come from a VB background where I felt that using Hungarian notation was appropriate.

Prefixing procedure names makes sense if you want to view the following as having prefixes - CustomerInsert, CustomerUpdate, CustomerDelete.

One constant exception that I make to that rule is when adding objects to another party's application database for an integration. I would prefix all of those objects with a 3 letter vendor designator, like abcCustomeExtrasInsert if I were working for the ABC company. I do this for 2 main reasons.

1. These objects will stand out as not belonging to the application's schema.

2. The next person who needs to find this code will have a good starting place. Hopefully that helps those who need to find it intuitively as well as those who know me.

I agree 100% with Gila Monster's comments, especially the last one regarding typing a few letters to get past the first few thousand objects in a list.

Tom Garth
Vertical Solutions[/url]

"There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers

Rich Mechaber SSChampion Points: 11130 More actions · Answer 4

I'll confess up front: I've never read Simonyi's original article.

I enjoyed this URL (Making Wrong Code Look Wrong) very much, in part b/c it emphasizes that Simonyi's original intent with Hungarian notation was, in fact, to "tell you the purpose, or intended use, of the object," which was your major complaint.

Maybe this is another version of that old, incendiary argument:

Hungarian notation doesn't kill databases, people who create useless object names kill databases? 🙂

Thanks for a great article, Phil! I always enjoy reading your blogs and articles.

Rich M.

M Chabot SSCrazy Points: 2511 More actions · Answer 5

I find that adding table prefixes helps from a developer standpoint. One of the most powerful tools that a developer has is the search command in an IDE. If a table is called "users," and your goal is to find every place where the users table is queried, a search for the word "users" might result in thousands of hits, most of them irrelevant, since that word might be commonly used throughout the application. If you follow the standard of naming the table tblUsers, then you can search on "tblUsers" and find exactly what you are looking for very quickly, since that isn't a word that would appear in any other context.

The primary reason I recommend tbl prefixes is to assist the find/replace command inside of the IDE, and the benefit is great enough in terms of increased productivity and easier site maintenance that it justifies their use.

Jedak SSCertifiable Points: 5576 More actions · Answer 6

mbarrington (1/25/2010)
While this doesn't invalidate any points made about archaic prefixing practices in people use in DBs, maybe you would be interested in this tidbit on Hungarian Notation...
http://www.joelonsoftware.com/articles/Wrong.html
If you skip down to "I’m Hungary" it talks about a great confusion with the concept.

I was going to post this as well, but you beat me to it. It's a very interesting difference. I personally don't mind Systems Hungarian.

For SQL Server I, prefix the following items in my T-SQL.

1. Stored procedures

2. Views

3. Indexes

4. Constraints

5. Keys

6. Defaults

I do it for two reasons.

1. It's the office standard.

2. I feel that it makes T-SQL code more readable.

Others may have different opinions and I have no problems with that.

kismert SSC Enthusiast Points: 102 More actions · Answer 7

Hah! Access -- the great coding-style polluter! I take a perverse pleasure in being part of the Access coding community, so reviled by its peers -- if only it wasn't so damn useful ...

For VBA/Access, I do tibble -- certain things in that IDE are just easier to work with that way. Access doesn't do subqueries well, so a prefix is handy to know when you are selecting from another query, or a table.

When I code PHP I don't use Hungarian notation, because PHP people don't do it. You don't need it, even for a loosely-typed language. The $ variable prefix is irritating at first, but it makes maintenance easier for coders who don't use an IDE.

For SQL Server, if it is a converted Access db with prefixes, I'll continue the convention. If it is tibble-less, I'll extend it in that fashion. The @ prefix for variables in procs and functions eliminates the need for more prefixing. I do like prefixing my indexes and relationships.

I feel Tables should be nouns, and functions verbs. So a function GetUserRecords(@userId) would act on a table UserRecords. Views should have compound names where appropriate, like UserRecordsWithUsers or UserRecordsForInactive.

-Ken

Phil Factor SSC-Insane Points: 20244 More actions · Answer 8

For quickly finding database object according to their category, use, or object type, you might find the extended properties invaluable, especially if you use the sys.extended_properties catalog view. You could even do your tibbling in an extended property rather than as a prefix to the object name itself. I do agree that prefixes are handy for cutting down on long lists in something like SQL Prompt, though.

Best wishes,
Phil Factor

GSquared SSC Guru Points: 260824 More actions · Answer 9

I dislike prefixing database objects.

I'm with the "you can't exec a table, so why does the name need to say so?" camp.

I've replaced tables with views (for backwards compatibility), much like Gail, and that breaks the whole concept.

I've seen plenty of databases where someone insisted on naming tables, "tblCustomers", but none of them would ever think of naming columns, "colAccountNumber". The whole point of naming conventions is standardization and consistency, so why wouldn't a column be prefixed with "col" in that case? Because it's patently idiotic and useless to do so! So why doesn't that apply to table names? Different "standards" for different things means they aren't actually "standards" at all.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Carlos Bossy SSChasing Mays Points: 643 More actions · Answer 10

I don't use hungarian notation in databases. I prefer clear, consistent and unabbreviated names such as CUSTOMER_LOCATION instead of tblCustLoc. If I have to distinguish between a view and a table I might name the view CUSTOMER_LOCATION_VIEW.

One point that hasn't been made and a reason why I normally don't use any type of special notation is that the users of the database (or data warehouse) are not always hard core developers. As a data architect I often have to consider report developers, business analysts, power business users, analytics people and help desk, among others. Even a power user using SAS for analytics might need access to complex stored procs. Giving these people names they are used to along with a great data dictionary makes life a lot easier from an enterprise point of view.

LinkedIn - http://www.linkedin.com/in/carlosbossy
Blog - http://www.carlosbossy.com
Follow me - @carlosbossy

mjswart SSC Enthusiast Points: 169 More actions · Answer 11

Ha!

CREATE PROCEDURE enTibble AS

DECLARE @tableName sysname = NULL;

DECLARE @newName sysname = NULL;

SELECT TOP (1) @tableName = name,

@newName = 'tbl' + name

FROM sys.tables

WHERE name not like 'tbl%';

WHILE (@tableName IS NOT NULL)

BEGIN

EXEC sp_rename @objname = @tableName,

@newname = @newName

SET @tableName = NULL;

SELECT TOP (1) @tableName = name,

@newName = 'tbl' + name

FROM sys.tables

WHERE name not like 'tbl%';

END

For what it's worth, I'm squarely in the anti-tibble camp.

mbarrington Grasshopper Points: 15 More actions · Answer 12

Jedak (1/25/2010)
For SQL Server I, prefix the following items in my T-SQL.
1. Stored procedures
2. Views
3. Indexes
4. Constraints
5. Keys
6. Defaults
I do it for two reasons.
1. It's the office standard.
2. I feel that it makes T-SQL code more readable.
Others may have different opinions and I have no problems with that.

Actually, I don't mind either. I believe you don't need a prefix for the type and, ideally, it's not advisable. But I do the same thing you mentioned for the same reason. Where I work, people also like to prefix objects to get them to sort a particular way, and to identify logical ownership (DBA, a certain app, etc.) It's very uncontrolled with lots of individual territories.

Is it "wrong"? I wouldn't be necessary if we had better DB organization.

But I've fussed a lot in the past at previous jobs about keeping things pure wrt style, standards, etc. In retrospect, the energy was better spent elsewhere because stuff like "tblManagers" is an easy vice to deal with.

Paul Stafford SSChasing Mays Points: 600 More actions · Answer 13

I once had the misfortune to work someplace where the prior DBA was so enamored with Hungarian notation that he had developed his own system. Every object had a 4 character prefix in front of it with each character representing some attribute about the object in question. trsc would mean you had a Table of Reference data for Sales about the Company.

Luckily he had written a 250 page naming convention document to keep it all clear:-D

OCTom SSChampion Points: 11785 More actions · Answer 14

I won't be quibbling with those who are tibbling but don't enjoy that which annoys.

I find a naming convention such as tblCustomers to be annoying. It is redundant and doesn't add any understanding. It would be hard to tell what it is without context but SSMS and code adds that.

SQLAJ Ten Centuries Points: 1359 More actions · Answer 15

Wow. Some heated discussion going on here.

I have used "tibbling" before but only because at the time I was a junior DBA/Developer.

I never really got why they would prefix tables with tbl. After all in the object browser when you expand the tables folder you don't find views or stored procs do you? Seems over kill and confusing on many aspects.

What one person uses for an acronym I may think of it differently.

I use a plain and easy approach by naming the object as close to it's use as possible.

Personnel

Customers

Addresses

Just my $.02 worth.

Cheers!

______________________________
AJ Mendo | @SQLAJ