• ichigo (unregistered)

    well damn...that's a pretty hard one :D

  • (cs)

    I can just see the conversation now...

    PHB: "This system you designed is great, but after deleting the test companies, the real companies are numbered nonconsecutively.  Can you redefine the CompanyIDs so all the companies are 1 through N?"

    Dev: "No, the system won't let me update the primary key."

    PHB: "Well... could you add a new key field then?"

    Dev. "... sure"

  • (cs)

    I'm truely at a loss for words, here... This is truely inexcusable.

  • Eric Wise (unregistered) in reply to ichigo

    I've seen something like this before and even though the naming convention is a WTF it did make some sense when I dug into the process.  Basically it went something like this:

    SQL Server based sales data system that did quoting and purchase records while the actual accounting system was Peachtree which has its own proprietary data files.  So basically you had a situation where a new customer would request a quote, so a company record would be created in the SQL server system.  Then if they actually purchased something and became a real customer they'd get a record in the accounting system (peachtree) which would have its own id.  Periodically they export peachtree data into the sql server so it could be accessed through their custom order/quote system.  The ID's had to both be on the record so the custom system could show the complete order trail of the customer from peachtree and all the quotes etc from the outer system.

    So yeah, there were two company IDs.

  • (cs)

    I am sure there is some genius formula to mathematically link the two fields together (reasons: secret; on need-to-know basis). And then, I am sure there are another two fields going by "Company Name" and "CompanyName" which require another translation logic to relate.

  • (cs) in reply to Eric Wise
    Anonymous:
    Periodically they export peachtree data into the sql server so it could be accessed through their custom order/quote system.  The ID's had to both be on the record so the custom system could show the complete order trail of the customer from peachtree and all the quotes etc from the outer system.

    So yeah, there were two company IDs.



    So then give them two different descriptive names that aren't merely seperated by a space!!!  
  • (cs)

    I'm wondering if we aren't kluging two separate sacred cow databases for some reason.
    If this is a temporary table, and we are doing this to enumerate the CompanyIDs for some report, this may not be a WTF after all.
    I hope Celko never finds out about this site...

  • (cs) in reply to Matt B
    Matt B:

    So then give them two different descriptive names that aren't merely seperated by a space!!!  


    Ah... but perhaps all the reporting was done in Access, which will auto-join tables if they have a field name in common.

    (Why am I defending this???)
  • (cs) in reply to Mike R
    Mike R:
    I'm truely at a loss for words, here... This is truely inexcusable.


    utterly, completely, fully, absolutely, far beyond, surely, sadly...
  • Eric Wise (unregistered) in reply to icelava

    icelava:
    I am sure there is some genius formula to mathematically link the two fields together (reasons: secret; on need-to-know basis). And then, I am sure there are another two fields going by "Company Name" and "CompanyName" which require another translation logic to relate.

    Heh, that was the other fun thing in the above system.  The names on the quotes weren't necessarily the names of the official buyer, so there was this whole mess of determining which name to display on reports etc since the quoting people know the customer by one name while the accounting system knew them by another.  Add to this the concept that 4-5 companies (school districts) would all have their own records tied to a master purchaser...

    It was a godawful mess.  I hated that system.

  • Rhett (unregistered)

    Maybe the original system was designed with an autogenerated PK.  But then they did some integration with another system and had to hold a reference to companies in the other system by another identifier.  That would reduce this to a minor WTF regarding naming of columns.

  • (cs)

    My eyes, the beer, it does nothing![B]

  • (cs)

    Just going by the two company IDs, this appears similar to a project I'm currently working on.

    It tracks training records, however, it has to allow for individuals who are in the system as an employee in one place, but could possibly hold multiple different jobs for which training records are tracked.  It's handled in a somewhat similar fashion, where their personid[1] is tied to a different employeeid which defines their possibly separate roles as an employee in two different places.  Possibly a WTF, but the original team that designed the app couldn't find a better way of handling that particular situation, so that's how it worked out.

    I could see this being something similar, however I can also see it as some PHB type wanting sequential CIDs for no good reason other than it looks pretty.

  • (cs) in reply to JThelen
    JThelen:
    It tracks training records, however, it has to allow for individuals who are in the system as an employee in one place, but could possibly hold multiple different jobs for which training records are tracked.  It's handled in a somewhat similar fashion, where their personid[1] is tied to a different employeeid which defines their possibly separate roles as an employee in two different places.  Possibly a WTF, but the original team that designed the app couldn't find a better way of handling that particular situation, so that's how it worked out.


    At least give the columns different names  
  • cdog (unregistered) in reply to Matt B

    Lots of people seem to be missing the idea.  Yeah, its fairly common to have two unique ID fields in a table due to merging of systems or trying to adapt to an existing system, etc.  The WTF here is the column names, which make it all to easy to fuck up when performing an action involving them.

    Also, imagine if there are business objects that handle these data... I wonder if the members are named CompanyID and Company_ID, or maybe CompanyID1 and CompanyID2.  Or perhaps CompanyID and CompanyId.  Hey... I just realized all the flexibility this naming scheme has to offer... brilliant!

  • AC (unregistered)

    What might be more disturbing is that when you view this WTF thats titled "Peeking On In" you see a google ad titled "Olga Panties". I was going to make some further joke about it here, but I really don't know how to respond to that combination.

  • (cs) in reply to Eric Wise
    Anonymous:

    I've seen something like this before and even though the naming convention is a WTF it did make some sense when I dug into the process.  Basically it went something like this:

    SQL Server based sales data system that did quoting and purchase records while the actual accounting system was Peachtree which has its own proprietary data files.  So basically you had a situation where a new customer would request a quote, so a company record would be created in the SQL server system.  Then if they actually purchased something and became a real customer they'd get a record in the accounting system (peachtree) which would have its own id.  Periodically they export peachtree data into the sql server so it could be accessed through their custom order/quote system.  The ID's had to both be on the record so the custom system could show the complete order trail of the customer from peachtree and all the quotes etc from the outer system.

    So yeah, there were two company IDs.



    Oy vey.  Later versions of PeachTree have an import/export capability in them.  I'm assuming that system probably began like this:

      1.  Someone discovers that it's possible to import/export data into Peachtree, so we write this cool webpage/app to input orders from outside Peachtree.
      2.  The webpage/app (let's just call it a tool) evolves with more features.  Eventually all quoting is moved off of Peachtree cuz it can be customized quite a bit, but the bean counters don't give a shit--they're not budging off Peachtree.
       3.  Since we are storing temp data in SQL, we can create some snazzy reports based on the data we're putting into Peachtree.
       4.  Now we have a kludgy system evolving, and it's just getting worse and worse as Peachtree data loses synch with the outside system.
       5.  After many lost hours of sleep, you finally realize maybe it would have been better to write a Peachtree data connector so you can read/write data into and out of Peachtree... or got rid of Peachtree completely and switch to Great Plains/SAP/whatever.

    I've dealt with that problem a zillion times.  ERP consulting pays some nice $$$
  • (cs) in reply to Matt B
    Matt B:

    At least give the columns different names  


    Well, we did do that, which is why I say it's similar.. the column names are actually there.. personid & employeeid
  • (cs) in reply to JThelen

    Man, and I thought my FATHER was bad about Naming Conventions...

  • John (unregistered) in reply to Eric Wise

    The real WTF here isn't that there's two different IDs that describe companies, that usually comes with a reasonable explaination, such as the PeachTree. The WTF here is having two ID fields differenetiated by a space.
    I shudder at the thought at all the typos in the code that supports this DB. Even if they didn't have any typos I can see a bug from QA, "BUG, P1 Critical, we entered '56' in CompanyID here and '56' in Company ID there and found we got two different companies"


  • (cs) in reply to JThelen

    JThelen:
    Matt B:

    At least give the columns different names  


    Well, we did do that, which is why I say it's similar.. the column names are actually there.. personid & employeeid

    That still isn't great, because it doesn't capture the reason behind the different names.  Something like CompanyID and PeachTreeID would be a better solution (in the other example in this thread)

  • (cs)

    I am now going to sell all my belongings and become a hermit in the wilderness and hunt for my food.  I want nothing to do with these damn computers anymore...  Ok, just kidding but this is fricking rediculous column names.  That is a friggin programming time bomb waiting to go off. [:D]

  • Pedant (unregistered) in reply to John
    Anonymous:
    The real WTF here isn't that there's two different IDs that describe companies, that usually comes with a reasonable explaination, such as the PeachTree. The WTF here is having two ID fields differenetiated by a space.
    I shudder at the thought at all the typos in the code that supports this DB. Even if they didn't have any typos I can see a bug from QA, "BUG, P1 Critical, we entered '56' in CompanyID here and '56' in Company ID there and found we got two different companies"



    The company/project I'm currently at would have that as a P3... Department affected.


  • x (unregistered)

    How long before Rik found out that the character before the D was a lowercase L?

  • (cs)

    Something like this could also make sense in the Java world if you're using Hibernate, which likes to have a meaningless autogenerated sequence as it's primary key no matter what.  The "CompanyID" field might have some actual meaning in the business process, and be shown to the user while the "Company ID" would be the otherwise meaningless primary key that Hibernate  uses.  From the naming here, and the fact that it seems to be a spreadsheet, that's clearly not the case.   

  • TB (unregistered)

    Well, I recently left a company with a similar design.  It wasn't from merging two systems, it wasn't from anything that had any real use.  It was from over-designing people that thought 2 IDs offered more flexibilty...anyway, they did name them slightly differently...but that didn't reduce the confusion.

  • (cs)

    Reminds me of a place where I used to work...a city government, no less.

    We had a bunch of hierarchial asset management data that used what was called a "facility id" as a primary key.  However, through years of neglect/errors, several of the tables developed multiple versions of ids.

    table1
    ------
    fac_id
    facid

    table2
    ------
    fac_id
    pfacid

    table3
    ------
    facid
    pfacid
    pfac_id

    "pfacid" meant "parent facility id" and served as the foreign key for one-to-many relationships.  The inconsistent/duplicated field names are obvious; what is not obvious is the fact that which field was "correct" depended on which tables you were joining together.  If you wanted to join table1 and table2, you used facid to pfacid.  If you wanted to join table 1 to table 3, you used fac_id to pfac_id.  If you wanted to join table 2 to table 3, you used fac_id to pfacid.  I actually had a document pinned to my cublicle wall so I could join the tables correctly.

    Oh, did I mention that the PK numbers changed every time they exported the data into database format?  So if you joined this week's table1 to last week's table2, you would get incorrect results.

    We asked the people creating the data to please clean this up and use a single, static id for each record.  They said no.

  • forgottenlord (unregistered) in reply to x

    Anonymous:
    How long before Rik found out that the character before the D was a lowercase L?

     

    That's just....no.

     

    No

     

    *cringes uncontrolably at the mere thought of that*

  • Anonymous Coward (unregistered)

    It seems to me that this is the product of a person who wasn't that good in databasing.

    Back in my younger (and more vulnerable years), I would always put some sort of auto-incrementing primary key in every table, and since I didn't know a lot about relational databasing, I would just persist a heckuvalotta data in every table. Always, I named these primary keys something like "CustomerID" or "ProductID"... I can easily see the above thing happening.

    Still not excusable, but I used to be an idiot, so I can understand it, at least.

  • (cs)

    Ah yes, that famous SQL ideal :  3rd abnormal.

  • Z (unregistered) in reply to icelava
    icelava:
    I am sure there is some genius formula to mathematically link the two fields together (reasons: secret; on need-to-know basis). And then, I am sure there are another two fields going by "Company Name" and "CompanyName" which require another translation logic to relate.


    For any sequenco of pairs of numbers, there is a polynomial that has those pairs as values.

    Therefore, the answer to any question of the type "what is the next number in the sequence", is always 17 (or 42, or 4711, or ...).
  • Binsky (unregistered) in reply to Z

    This was indeed very silly!

    But I must admit that I have also done something similar...At my last job I made a tool that communicated with a bunch of devices, and those devices had a way to determine their own hardware addresses at startup. Because that meant that the devices would be found in a different order each time they were started up. Someone above mentioned something about a management type saying : "but can't those be re-ordered again?" *shrugs* Oh well, I gave them what they asked for....And ended up with three different ID's to communicate with the same string of devices! At least I had the sense to use clear names for my variables, and almost never mixed those up! :p

    Binsky

     

  • Justin (unregistered) in reply to Eric Wise
    Anonymous:

    I've seen something like this before and even though the naming convention is a WTF it did make some sense when I dug into the process.  Basically it went something like this:

    SQL Server based sales data system that did quoting and purchase records while the actual accounting system was Peachtree which has its own proprietary data files.  So basically you had a situation where a new customer would request a quote, so a company record would be created in the SQL server system.  Then if they actually purchased something and became a real customer they'd get a record in the accounting system (peachtree) which would have its own id.  Periodically they export peachtree data into the sql server so it could be accessed through their custom order/quote system.  The ID's had to both be on the record so the custom system could show the complete order trail of the customer from peachtree and all the quotes etc from the outer system.

    So yeah, there were two company IDs.



    ...so you gave them meaningful names, right?  Something like "peachtree_company_id" and "sql_server_company_id"!

    It's not unusual to have more than one id associated with a business object.  Calling them the same thing bar a single space is a definite WTF.

    Justin.
  • MLB (unregistered) in reply to Binsky

    I often find myself in situations where I have multiple keys for essentially the same thing and some kind of map is necessary. For example, if you're using some external programs or libraries that haven't been very well designed and insist on their own input files. I usually handle this sort of stuff at run-time so a lot of error checking can be added but, if it is static enough a simple table seems like a sane way to handle it.  The only thing wrong here (as pointed out elsewhere) is the names. You would expect something like

    Company_ID   ID_for_lame_legacy_app
    0                               42
    1                                21
    2                                668


  • (cs) in reply to MLB

    I know that a space is a valid characher in a table name, but why use it?! the space is almost always used as a delimiter between statments/commands/(words).. try doing: SELECT * from [table] WHERE Company ID = 5

    then try doing a complicated SQL statment, and see how many times you forget to quote the field name: SELECT blah, company ID, blah2, CompanyID, blah3 with spaces FROM [table] JOIN [table2] ON table.Company ID = table2.joinField

    imo, any table/field/database name should be a valid variable name, i.e. it matches ([a-zA-Z_][0-9a-zA-Z])

  • (cs)

    Without doubt the column naming is extremely stupid. Besides that, it often makes sense to have internal IDs (always unique, never changing) additionally to the existing "number" (customer number, product number).

    Example one: A company regulary changes product numbers. Don't ask me why, enough to say they do it. As a result, if you have internal IDs (and use them for all references), you have to update one record. If you rely on the product number (the old system did that), you have to work through 15+ tables to update the product number there.

    Example two: After some years of running the system, a company decides to use the system for their subsidiaries, too; and for some reason, it shall run in the same database. But the subsidiaries have their own client number, product number etc. which overlap with the companies numbers. If you have internal IDs, the necessary modifications are much smaller and less dangerous.

  • Squig the Squog (unregistered)

    The thing is, I bet that a good proportion of the people lambasting this CompanyID/Company ID stupidity also support the almost exactly stupid notion of having variables names differing only by case. I'm looking at all you C/C++ afictionados out there in particular.

    Why is CompanyID/Company ID in your database bad, but CompanyID/companyID in your code a good thing?

  • boohiss (unregistered) in reply to Squig the Squog
    Why is CompanyID/Company ID in your database bad, but CompanyID/companyID in your code a good thing?

    That doesn't sound like something I've seen a lot, or even use in C/C++. However, in the case you mentioned, it's clear to me that CompanyID is probably a class, and companyID is an instance of that class. Whereas, to the Access/database programmer, the column names make things very unclear and confusing.

  • (cs) in reply to Squig the Squog
    Anonymous:
    The thing is, I bet that a good proportion of the people lambasting this CompanyID/Company ID stupidity also support the almost exactly stupid notion of having variables names differing only by case. I'm looking at all you C/C++ afictionados out there in particular.

    Why is CompanyID/Company ID in your database bad, but CompanyID/companyID in your code a good thing?


    Clearly you don't want the names to be confused at a glance, so you change them up slightly, but something like
    Employee empl = new Employee();
    can be useful, if an uppercase consistently indicates a Class name, and lower case is an instance of the Class.
    Of course the Standard Template Library takes the all lower-case approach, so your typedefs may vary...
  • MLB (unregistered) in reply to smitty_one_each
    smitty_one_each:
    Anonymous:
    The thing is, I bet that a good proportion of the people lambasting this CompanyID/Company ID stupidity also support the almost exactly stupid notion of having variables names differing only by case. I'm looking at all you C/C++ afictionados out there in particular.

    Why is CompanyID/Company ID in your database bad, but CompanyID/companyID in your code a good thing?


    Clearly you don't want the names to be confused at a glance, so you change them up slightly, but something like
    Employee empl = new Employee();
    can be useful, if an uppercase consistently indicates a Class name, and lower case is an instance of the Class.
    Of course the Standard Template Library takes the all lower-case approach, so your typedefs may vary...


    The simple answer is, you _do_ want to use a consistent approach with the upper and lower case letters, but you _don't_ want something like Employee *employee=new Employee();
  • MLB (unregistered) in reply to smitty_one_each
    smitty_one_each:
    Anonymous:
    The thing is, I bet that a good proportion of the people lambasting this CompanyID/Company ID stupidity also support the almost exactly stupid notion of having variables names differing only by case. I'm looking at all you C/C++ afictionados out there in particular.

    Why is CompanyID/Company ID in your database bad, but CompanyID/companyID in your code a good thing?


    Clearly you don't want the names to be confused at a glance, so you change them up slightly, but something like
    Employee empl = new Employee();
    can be useful, if an uppercase consistently indicates a Class name, and lower case is an instance of the Class.
    Of course the Standard Template Library takes the all lower-case approach, so your typedefs may vary...


    The simple answer is, you _do_ want to use a consistent approach with the upper and lower case letters, but you _don't_ want something like Employee *employee=new Employee();
  • (cs) in reply to MLB
    Anonymous:

    The simple answer is, you _do_ want to use a consistent approach with the upper and lower case letters, but you _don't_ want something like Employee *employee=new Employee();


    Why not? Things like this are quite common. As long as upper case consistently means "class", I see no problem.
  • anon (unregistered) in reply to Squig the Squog
    Anonymous:
    Why is CompanyID/Company ID in your database bad, but CompanyID/companyID in your code a good thing?


    It's still not a good thing, in general; and the only time it's even vaguely tolerable is if you have two variables of completely different types with no conversions between them.
  • Scott (unregistered)

    Not sure what the problem is here.... CompanyID is likely the ID assigned to these companies before the system was ever built, and hence the id in their record books.

    Company ID is just a autoincremented primary key, I'm sure. Nothing more than a point of reference, but this isn't much of a WTF. First glances can be deceiving :)

     

  • Squig the Squog (unregistered) in reply to ammoQ
    ammoQ:
    Anonymous:

    The simple answer is, you _do_ want to use a consistent approach with the upper and lower case letters, but you _don't_ want something like Employee *employee=new Employee();


    Why not? Things like this are quite common. As long as upper case consistently means "class", I see no problem.

    "Why not? Things like this are quite common. As long as XXX[space]X consistantly means 'internal', I see no problem."

    The problem is, as I was trying to allude to, that 'CustomerID'/'customerID' is exactly the same kind of "the same but different" arbitary decision that we really should be laughing and pointing at.

    Case sensitivity and space sensitivity are equally moronic when it comes to identifiers that humans read. Your system isn't going to slow down and die because you use descriptive names that have a clear meaning to the people reading them.

    (To anyone who took my original question at face value - it was rhetorical. I wasn't suggesting in any way that case sensitivity is good and asking for reasons).
  • (cs) in reply to Squig the Squog

    He should have at least named one of the Company IDs something like "Old Company ID". That at least, I would've understood.  

  • (cs) in reply to Candle

    Candle:
    I know that a space is a valid characher in a table name (...)

    A space is NOT a valid character in a table name.  That's why you have to use delimiters.  And it's a bad idea to use them.

  • (cs) in reply to Bustaz Kool

    There's a strong tradition of case-insensitivity in SQL-land.  It would be disastrous to have field names that differed only by case - in fact, many implementations won't even let you create field names that differ only in case.

    On the other hand, there's a strong tradition of case-sensitivity in C-land.  (JScript is an aberration.)  It is much more acceptable to have things like

    Object object = new ...

  • (cs) in reply to MLB

    Anonymous:

    The simple answer is, you _do_ want to use a consistent approach with the upper and lower case letters, but you _don't_ want something like Employee *employee=new Employee();

    I do exactly this all the time. I would never mix-up "employee" and "Employee" in that example. However, if I did, the compiler would tell me about it pretty quickly. Classes and instances are not interchangeable like that.

    Now, if I had two classes or two instances of a class or two fields in a table that differed only by case, that would be a huge WTF.

  • (cs) in reply to Maurits
    Maurits:
    Object object = new ...

    er, Object object = something_that_returns_an_object() (new returns a pointer, duh)

Leave a comment on “Peeking On In”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article