Naming Is Hard

  • Comments posted to this topic are about the item Naming Is Hard

  • I think if you found someone using GUID's for table names my guess is the tables were created by some program and not by a DBA or developer.

  • david.leyden (4/6/2016)

    I think if you found someone using GUID's for table names my guess is the tables were created by some program and not by a DBA or developer.

    I had exactly the same thought. I have worked with a system that did not have the luxury of row-level security, where the database supported a multi-client product and it was necessary to create a table per client that was then aliased to a common readable name in the client access layer. Although it didn't use a GUID, it did use an abstract naming process, and all the objects and access code were auto-generated by a management app.

    Maybe not the best way, but it worked and the system was safely partitioned.

  • david.leyden (4/6/2016)

    I think if you found someone using GUID's for table names my guess is the tables were created by some program and not by a DBA or developer.

    Probably, but someone decided to create and use that tool. That decision was totally wrong in my opinion.


    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I am very much in favour of using clear and sensible naming conventions. The first example I had of rubbish naming was when I had to debug some C code in my early days in IT. Whilst the initial functions were clear some subsequently added were far from. The guy who had modified the initial code had done things like small int mouse, large int elephant. This all seemed to be part of a game so he could write code like "gecko = reptile", etc. Some lines were distinctly crude so not worth repeating. It was all very confusing as a sensibly name d argument became a rubbish one! Subsequently the company introduced coding standards...

  • My programmers insist on me creating all objects, even columns because I never like how they name them. I agree that a good name for a table is necessary, but I take it even further. You only abbreviate things that make it into the standards document such as nbr = number. Otherwise you spell it out.

  • Ah, naming. Be it tables/columns/indexes/et al or variables/subs/functions/etc. there's no subject in the programming world that generates quite so much controversy.

    I think it's because it's so intensely personal. We've got strict naming policies here and I find it helps me almost always win the "guess the name" game, but I had the luxury of setting up the conventions...

    Let the fun begin!

  • "Either the people in charge of naming weren't creative, or they were very, very lazy"

    Well I don't know if that is fair. Without knowing why they used the names they used, calling them lazy or saying they aren't creative is a bit harsh. I find that if we try to "walk in the other's shoes" we can sometimes understand the motivation, and frequently agree with why they did what they did. For street names, what if the developer was named Wolfe? Where I live there is a standard, I don't recall what it is called, where N-S streets are all trees, and E-W streets are all numbered on the North side of towns, and start with A, B, C on the South. Every area probably uses some standard, and while we may not understand it, that doesn't mean there isn't one.

    For computer systems, the same thing applies. One prominent ERP system has very short table names. This is likely because it was written in Cobol and ported to Windows so it could use MS SQL Server. They can't just change the table names without a LOT of work. So the names are things like EMPLOYEE, DEPTCODE, PRTIME and PAPOSITION. The first is really helpful, the last is OK. Then we get into names that I can't remember at all and have to look up every time I write a query. Some of those seem to be no more than a collection of letters.

    Another system uses 3-letter codes to group data. ORD stands for orders, EMP for Employees, but they quickly ran out of obvious abbreviations. Some of them you look at and wonder why they used that code, but if you know the history, you understand the limitation that the developer was under.

    I find naming to be difficult, and frequently start with one thing, and then go back and change to something better as I understand the system better. I try to rename older items, but that isn't always possible. Your point about how we should try to use names that have meaning is a good one, but frequently we inherit something that someone else started and changing mid stream may be worse.


  • Apparently a developer or DBA at some point decided it wasn't worth trying to name tables to match some entity and used GUIDs are names instead

    I hate that person. Unreservedly and without measure.

    Also those who use a GetPersonDetails approach to naming rather than EntityActionQualifier - I often want to ask them if they'd have a project where they'd create a class that sets all their properties. Then think better of it, just, you know, in case they ...

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • .. The tables in a JD Edwards system were coded with a short alpha sequence and then a 4 or 5 digit number. Always fun to remember what "FS3401" means...

    Ha! I'll bet you're talking about PeopleSoft.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Not just Colorado.... Cape Coral, FL... although there are exceptions, streets that can get you from Point-A to Point-B (lots of streets cannot do that - the place is half streets, half canals) are named with words (Santa Barbara, Del Prado, Cape Coral Parkway - they thought long and hard on that one). However, a vast majority of streets are numbered, and each number may have 9 (12?) versions: 14th St, 14th Pl, 14th Ave, etc.

    To top it off, depending on where you are in the city, it might be NE 14th, SE 14th, NW 14th, or SW 14th.

    There was a method to the madness, though. Each address included where on the city's grid that address was. 1704 SW 14th (whatever) placed that address on SW 14th, and the streets running perpendicular to SW 14th would be SW 17th (whatever). And you could tell if the street ran north/south or east/west by whether it was ST, PL, AVE, DR, etc. If you were new to the city, the reaction was always WTF?!? But once you learned the madness' method you could get from Point-A to Point-B, maybe even without a map.

  • OK clearly using a bunch of numbers makes little sense. But you can go overboard the other direction too. I think our column names are sometimes too long and become basically unreadable.

    Here is an example: USBankEPaymentSchedulePaymentMessageProductParameterID

  • It's possible the GUID tablenames was done for 'security' reasons. No interloper would know what the table was for based on the name....still doesn't make it right, but that is a possibility.

    As for street/road names....I live in Arizona, many areas use the exact same street name in the same development. For example: when I was looking for a house to buy, one neighborhood had three Turquoise Street roads. None of them connected. The only thing different was the numbering of the houses. Oh, and all three Turquoise Streets had a Topaz Street connected to them. Makes if real fun trying to give directions. If you enter the neighborhood from the north, go this way to Turquoise St, then turn onto Topaz St. If the addresses are in the hundreds or thousands, you are on the wrong Turquoise...if they are in the 10 thousands, you are on the right street. But if you come from the east, don't turn on Turquoise St, go this way, and then turn on Turquoise St, then turn onto Topaz St. Sheesh.....


  • Eric M Russell (4/7/2016)

    .. The tables in a JD Edwards system were coded with a short alpha sequence and then a 4 or 5 digit number. Always fun to remember what "FS3401" means...

    Ha! I'll bet you're talking about PeopleSoft.

    Or about Microsoft Great Plains (Dynamics).....

  • Naming conventions are weird, as long as they're consistent I can live with them though. My favorite was working with an open source esales database developed by a company in spain and well being from spain they used latin style grammar for all the table and column names so shipping_address would be address_shipping, nothing wrong with that but super easy to miss if you're not careful and used to english style naming.

Viewing 15 posts - 1 through 15 (of 33 total)

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