• Alex Papadimoulis (unregistered)

    I'll start it off ...

    I see absolutely nothing wrong with this. How much more helpful would "Bank Statements" be instead of BNK? If you're jumping in to maintain the system, you're going to be lost no matter how the table names are.

    Personally, I prefer two letters for table names. Saves more space that way. When you take into account International letters, you can easily get 1000 tables that way.

  • Randy Glenn (unregistered)

    Two letters? Luxury! When I was but a lad, our RDBMSes only let us use 16-bit binary values in our SQL - and the 1s didn't always work!

    And we liked it!

  • Hassan Voyeau (unregistered)

    You're going to be lost anyway but you would be less lost if the tables had descriptive names.

  • Barry Etter (unregistered)

    Maybe it's just a database of TLAs (Three-Letter Acronyms).

  • ABA (unregistered)

    CO2? ASS.

  • Jason Barnabe (unregistered)

    It's not so bad if they have a dictionary of table and column names, which is common in big businesses.

  • sebmol (unregistered)

    Alex: how is somebody else to understand this table name mess once they "get to" maintain it? of course, you will have extensive documentation that will explain what each table does. yeah, right.

  • Alex Papadimoulis (unregistered)

    ** Sarcasm **

    It's a rule. Some one always has to go and say "You know ... I dont see anything wrong with this."

  • Phil Scott (unregistered)

    Alex, you forgot to add the part where someone says in a condescending tone that "obviously you haven't done any serious development in the <whatever> field."

  • [email protected] (Haacked) (unregistered)

    C'mon people, these are actual words. Obviously you're not Scrabble champions. Look at table 1, obviously this is a table of Abba's greatest hits. It's rather small. And the second one, have you never heard of an "ACC"? That's a distant primitive relative of the Yak.

  • Larry Osterman (unregistered)

    Could those be language tags? I know that some of them are.

  • Omer van Kloeten (unregistered)

    Where's the decode table for these?

    There could be a whole new syntax for SQL:

    SELECT *
    FROM (SELECT TableName FROM TableNames WHERE LongName="Bank Statements");

    Would be like:


  • Phil Scott (unregistered)

    I think for your code to work Omer, you'd need to use the exec function ala:
    DECLARE @tableName varchar(255)
    SELECT @tableName = TableName FROM TableNames WHERE LongName="Bank Statements"
    exec ('SELECT * FROM + @tableName)

    Can you do this without a variable? I don't know, and it's too late on a friday to care :) But the real question: could you write this as an UDF? That way we could do a SELECT * FROM dbo.GetTable("Bank Statements")

    That would be sweeeeeeeeeeeeat

  • Craig (unregistered)

    You guys are a bunch of whiners. At my company, all our tablenames are in binary. Not sure why but it made sense at the time.

  • Colin Angus Mackay (unregistered)

    Well, The table names remind me of a dataset produced by the US Census Department or the USGS or some such organisation. The fact that the database is called Tiger leads me to think that is is geography for census data (There is a dataset called Tiger Line produced by the US Census Bureau) which is often imported in to GIS systems. And finally the Server is called "TROY" - MapInfo Corp. are located in Troy, New York and would be a natural user or supplier of Tiger Line data.

    So, the question is... Does John Carter work for MapInfo? Or have I just pulled lots of random facts and firmly grasped the wrong end of the stick?

  • Ilya Haykinson (unregistered)

    I agree with Craig, you guys are whiners. At least these are three characters of ASCII. What if the table names were twenty characters in extended Unicode 3.0 characters? Using diacritics? Characters which do not have a printable representation (other than the ?)?
    Unicode line drawing characters (¦¦¦+-+¦)? Feh, this three-ASCII-character name doesn't scare me nearly as much as someone really trying to obfuscate the meaning here.

  • Ilya Haykinson (unregistered)

    Ok, so the chars don't come through as they should... should have used &#61450; style references... :)

  • TJ (unregistered)

    But did u guys notice that there is a table in there that is duplicated and only thing different is the table owner. Take a look at the bottom "CRP"

  • Phil Scott (unregistered)

    Btw, I think Colin is right about the Tiger data format. Which is pretty funny, because some people were at my office getting training on using the Census data and I heard them talking about column names and codes and actually paused in the hallway and listed to them because the guy was basically speaking in gibberish.

    I walked away and only could say "WTF?"

  • Angstrom (unregistered)

    Anyone else notice there appear to be two 'BKR' tables with different owners?

  • Skikic (unregistered)


    I wonder what the scalability plan would be ...

  • Peter Ibbotson (unregistered)

    I have to say that we're not much better.

    We do have an excuse, bits of the codes base date back to the 80's and field names weren't unique to a file, Individual field names could
    only go up to 15 characters, so we went with a 3 character "filename" plus a period followed by 11 characters for the fieldname.

    This was a programming language problem rather than an underlying database problem, but its still leaving it's mark nearly twenty years later.

    Note to self, remember to ditch this on the next version (it's embarassing).

  • cablito (unregistered)

    Yeah, right, there is a perfectly reasonable reason for this. lol

    The tables with the same name but different owner must really be easy to mantain!

  • Mark Mullin (unregistered)

    In general a good point, but I too wonder if this is TIGER data - in some databases (my case, tables that carry about 150 quarterly financial measurements for all publically traded companies) have columns that are named by rules, i.e. the column name has to be distinct across the set of tables and it's primarily autogenerated (ours come from statement_type:financial criteria)

    In our case, we add descriptive metadata that describes the column, but we use a fixed 4 character naming convention, where the names are generated from a function that takes in the long winded name and some hardwired data (some financial statements carry data with the same name as others that is not 'truly' a duplicate - since our users can generate ad-hoc queries that map across all of the tables, these short cryptic column names are how we keep our sanity, not loose it - yes it's counterintuitive, but not every situation calls for long winded column names - yes we could do internal translation to long names, but we've got screen scrapers, report generators, visualization tools, and mess of other stuff hitting the database

    Descriptive names are like goto statements - most of the time the common wisdom is wisdom, but there are certain cases where it's counterproductive.

  • Sleestak (unregistered)

    I've seen plenty of databases like this where the sql db was essentially a front-end to a mainframe db where the system DID enforce tiny little table names, or the tables had been around for so long (pre-SQL days) that you were stuck with the names.

  • Peter (unregistered)

    You know, when the aliens blow up the Earth, it won't be to make a hyperspatial bypass, or because we are obstructing their view of venus. Nope. They are going to blow us up because we use acronyms. And the last thing that the last human left alive will say is "WTF?" And the alien taking their tentacle off the firing button will say "exactly."

  • Shawn (unregistered)

    I hate it when people don't remove the Pubs and Northwind databases. I don't know why but it bugs me.

  • Distilled Software Hate (unregistered)

    This list of table names is reminding me of SAP. The only GUI application I know that makes CMS look user-friendly.

    Oh my god, I have to do my time card.

  • AL (unregistered)

    tee heee!


    CAPTCHA: secundum: unsolvable. The act of succumbing to a conundrum.

Leave a comment on “Good Table Names, Redux”

Log In or post as a guest

Replying to comment #:

« Return to Article