This post originated from an RSS feed registered with .NET Buzz by Darrell Norton. Original Post: Making database names friendly (or at least readable) Feed Title: Darrell Norton's Blog Feed URL: /error.htm?aspxerrorpath=/blogs/darrell.norton/Rss.aspx Feed Description: Agile Software Development: Scrum, XP, et al with .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Darrell Norton Latest Posts From Darrell Norton's Blog

Most DBAs want to name each column something ridiculous (to developers, anyway) like A_PrdCdPct for a period code percentage amount. And the table is named AbcPrdCd; obviously that’s the Period Code table for the Abc application. Duh.

Recently I’ve come to the conclusion that database column and table names should be made “developer-friendly” in the database. If database access is solely through stored procs, it is easy to alias each column and table name, like this within the proc:

SELECT
I_PrdCdId as PeriodCodeID,
A_PrdCdPct as PeriodCodePercent
FROM AbcPrdCd as PeriodCode

If direct SQL access is needed, then views work well, although there may be a performance penalty when using views (although indexed views can help). Views are also useful when you want to transparently control user access to tables.

I usually don’t like to add additional layers of abstraction unless absolutely necessary, however I think the return for this small amount of work is big. I can’t count how many times the DBA group said, “Oh, we named that wrong so we changed it yesterday” as I sat there trying to figure out why stuff I checked in yesterday doesn’t work today. Yes communication would help, but better yet, let’s get rid of the whole problem! This would allow the DBAs to change column names to their hearts' content and our applications can remain blissfully unaware.