Along with many others we had long indulged ourselves in the practice of assigning alias names to database tables and fields in the hope that our assigned alias would be more “meaningful” to the end user. Balderdash! (We say now taking full benefit of 20-20 hindsight.)
Your honor, here’s our case.
- The object should be named clearly in the first place! In Oracle we have 31 characters. This should be plenty to provide a concise description of most anything. HIGH_SIDE_GROUNDING_METHOD is 26. Gazillions of us communicate entire thoughts via Twitter in 140 character or less bursts. We have the vocabulary to do this. Abbreviate if necessary.
- If we can’t describe the object clearly by name why do we think an alias will be clearer? How many would really find “High Side Grounding Method” easier to understand than HIGH_SIDE_GROUNDING_METHOD? Please!
- (And this is the kicker.) It’s an absolute maintenance and support nightmare! Put yourself in the support analyst role for a second and consider a call you get from a user about an unexpected value in a field they see as “Type”. In the database the analyst knows there is a field named SUBTYPE_CODE, a field named TRANSFORMER_TYPE, and a field named WINDING_TYPE. How long do you think it will take the analyst to figure out which of these fields is at issue? How frustrated will the end user get in the process?
We’ll even pass on the cases where an alias gets mis-assigned. (Ever copy a field in your data model, assign a new name but forget to re-assign the alias?)
With that your honor the defense rests. Ladies and gentlemen of the jury it’s now up to you. We’ll leave you with one last thought. Think for a moment as a database “alias” as a “nickname” or an AKA. Have you ever had a nickname — other than one you gave yourself — that you really liked? Just saying.
