• faoileag (unregistered) in reply to Miriam
    Miriam:
    I feel kind of bad for Erik
    Laudable, since no one else does :-)
    Miriam:
    It seems like his articles are disliked overwhelmingly often
    The problem is: if you compare Erik's articles with those of say, Lorne, Snoofle or Remy, then you can't help but think that Erik's approach as an author for TDWTF is more like "seed me with something (a submission) and I write a story", whereas the other authors' approach is like "ok, this submission is a bit dry, let's but some flesh on it".

    Go to Erik's twitter account and you will find that he proclaims himself to be a writer.

    Only, neither his "Hanzo" series nor his "Sergio" series have been good reads.

    And he knows how his TDWTF articles are received. He claims not to read the comments left by his audience, because he has "a small but vocal hatedom [with the TDWTF readers]".

  • faoileag (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Did they? Have a link?
    Can be found when searching twitter ;-)

    Sorry, I don't want to post the link here.

  • Jake (unregistered) in reply to faoileag
    failego:
    insert_your_favourite_french_speaking_place_in_the_world
    FILE_NOT_FOUND!
  • (cs) in reply to faoileag
    faoileag:

    And of course it is enterprisy. You can pinpoint a position to a hitherto unknown precision of (roughly) 1.1 e-247 m!

    For the science pedants amongst us:

    1 planck length = 1.61619926 × 10-35 meters
    So you're only 10^212 smaller than anything possibly can be.

    Or maybe their lat/long is in units of teraparsecs...

  • (cs) in reply to Heisenberg
    Heisenberg:
    faoileag:
    And of course it is enterprisy. You can pinpoint a position to a hitherto unknown precision of (roughly) 1.1 e-247 m!
    I'm not so certain.

    Rating: +6.02e23

    But I'm completely certain, so long as you stay there for roughly 1.1e247 seconds :-)

  • Mr. AHole DBA (unregistered)

    One day this legacy code will be ported over to a document store like MongoDB if they hit performance issues, assuming they don't need ACID compliance. Nothing wrong with denormalization in the days of 64 bit computing but damn... what a nightmare to remember all the names of.

  • Mr. AHole DBA (unregistered) in reply to Zog
    Zog:
    Single table, no normalisation....these days we call that NoSQL and BigData

    We only call that NoSQL, and although NoSQL has helped big data tremendously, just using a solution like Mongo doesn't mean you're big data. Far far from it.

    Your first clue that somethings not 'big data' is if it can be managed in traditional relational databases, be backed up, be performant, and not collapse over on itself when someone tries to look at it.

  • (cs) in reply to faoileag
    faoileag:
    So instead of three tables (FIP_CAI, FIP_INP, FIP_DEG) you just got one. Big deal.

    And not necessarily a wtf. If data from all three tables is routinely used together, why bother with a join or three separate selects each and every time?

    Unless we know the code that works with the data, we can't tell if this represents a wtf.

    And if an ORM comes into play as well the schema is perfectly fine as it will represent the fields of an object. Ok, then the architect of that object might be to blame (composite pattern anyone?), but the poor database schema is innocent.

    Yup. We don't even know what role the CAI, INP, and DEG entities play.

    Data normalization isn't about keeping the number of columns in a table down. A properly normalized table could have unboundedly many columns, if all of those columns are necessary to define the entity the each row represents.

    Another snoozer from The Daily We're The Fuck.

  • (cs)

    Such demoralized structure of table make it easy to write reports.

  • Captain Obvious (unregistered) in reply to Squiggle

    I prescribe 1 bottle McCallen 18 year - STAT!

    Consume entire bottle or stop when you pass out.

    (You're welcome)

  • (cs) in reply to Buck
    Buck:
    > TRWTF is the VARCHAR(255) for FIP_INP_GEOPOSLONG and FIP_INP_GEOPOSLAT.

    Duplicate columns.

    FIP_INP_GEOPOSLONG: VARCHAR(255) FIP_INP_GEOPOSLAT: VARCHAR(255) FIP_INP_GMAPSLNG: FLOAT FIP_INP_GMAPSLAT: FLOAT

    They apparently needed to store the lat/lon formatted for presentation as well as 'raw' for calculation purposes.

    When it comes to storing things like dates and coordinates as VARCHARs, there's one clear-cut case where it's ok: when you need to store raw data and don't have a guaranteed input format. It may be possible that they get dirty data, store it in the GEOPOS fields, then try to clean it and put it in the GMAPS fields. Or maybe even use the address information and generate the GMAPS fields using Google Maps' Encoder library.

    Same goes for dates. If you don't know what format to expect it in, and you don't need to do any calculations, just take any sort of string, and display that.

  • Slapout (unregistered)
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

  • (cs)

    Why is it that "xxxx left shortly thereafter" is always the end of the story? Maybe TRWTF is that the hapless employee doesn't have the interviewing skills necessary to determine whether the job is a good one or not, before accepting the offer.

    I have to admit that I was one of those people, who accepted a job offer, not really knowing what kind of product I'd be working on or what the company environment was actually like.

    But if WTFery is going on at a company, you as a prospective employee should be able to ferret that out before accepting the job.

    At least these people know to get out before it affects their career.

  • (cs) in reply to faoileag
    faoileag:
    Medinoc:
    faoileag:
    http://dev.mysql.com/doc/refman/5.0/en/char.html:
    The CHAR and VARCHAR types are declared with a length that indicates the maximum number of characters you want to store ... Values in VARCHAR columns are variable-length strings
    That doesn't mean it actually takes variable space. From experience, both CHAR and VARCHAR are still fixed-length buffers in the DB record, and the only difference is that VARCHARs are not returned padded with spaces.
    Do they? Then I stand corrected...
    Um, in Oracle, varchar2's only take up what you use. That is, a varchar2(4000) with "Hello world" will only take up 11 bytes (plus whatever Oracle uses to keep track of it).
  • (cs) in reply to Slapout
    Slapout:
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

    You're thinking of "single letter variables", not "single-letter variables."

    At least you're not ranting against them having punctuation out of caps lock.

  • anonymous (unregistered) in reply to chubertdev
    chubertdev:
    Slapout:
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

    You're thinking of "single letter variables", not "single-letter variables."

    At least you're not ranting against them having punctuation out of caps lock.

    Caps lock isn't required for having punctuation. In fact, caps lock has no effect on punctuation (unless you're French).

  • faoileag (unregistered) in reply to cellocgw
    cellocgw:
    faoileag:
    You can pinpoint a position to a hitherto unknown precision of (roughly) 1.1 e-247 m!

    For the science pedants amongst us:

    1 planck length = 1.61619926 × 10-35 meters
    So you're only 10^212 smaller than anything possibly can be.

    As I said: hitherto unknown precision! :)

  • (cs) in reply to Squiggle
    Squiggle:
    Only 146 columns?

    I used to work on a system that had 2100 columns split across 16 tables which all shared one single primary key.

    Which RDB were you using? I've had issues before with third-party software on SQL Server since there's a limit on how wide you can make a table.

  • (cs) in reply to anonymous
    anonymous:
    chubertdev:
    Slapout:
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

    You're thinking of "single letter variables", not "single-letter variables."

    At least you're not ranting against them having punctuation out of caps lock.

    Caps lock isn't required for having punctuation. In fact, caps lock has no effect on punctuation (unless you're French).

    The letters create the punctation, and thus the caps lock refers to the letters. You don't want an "a" to bear children before it grows up to be an "A."

  • nmclean (unregistered) in reply to someguy
    someguy:
    TRWTF is that Erik Gern didn't split this post into three parts and add lots of unbelievable embellishments.
    Multiple posts!? Why bother?
  • (cs) in reply to DrPepper
    DrPepper:
    Why is it that "xxxx left shortly thereafter" is always the end of the story? Maybe TRWTF is that the hapless employee doesn't have the interviewing skills necessary to determine whether the job is a good one or not, before accepting the offer...
    Sometimes they lie to you during the interview...

    Yes, we have proper source control (translation: defined as copying the entire source tree to another directory and manually migrating changes)

    Yes, we have proper documentation (translation: a local text file with some notes on Fred's PC)

    Yes, we have requirements (translation: Charlie scribbled a picture of the UI on a coffee-stained napkin; build it from that)

    Yes, we have a proper production support team so the developers can concentrate on their jobs (translation: the VP passes complaints to the dev team, and they take precedence; you can code after support ends at the end of the day)

    The trick is to spot the problems as quickly as possible, while your second choice is still available, and be willing to jump.

  • (cs)

    I don't really see the WTF, the columns make sense to me.

    This database table is about heritage sites and while a lot of information is maintained, it is all relevant to one specific site. The information contained falls into 3 categories:

    1. all columns that start with FIP_CAI contain practical information about the site, such as its address and phone number.
    2. FIP_INP columns contain information about accessibility of the site and services offered. Some information is about accessibility for disabled people, people with vision or hearing impairments, etc.
    3. FIP_DEG contains other background information about the site, such as its background, original name, size, construction materials used, etc.

    Sure, there are some things that could be better such as duplicate rows for coördinates, but overall the table design is not really that bad. It wouldn't make sense to store the accessbility information in a different table, as this information is very specific to the site. The likelyhood of having two heritage sites that have exactly the same accessibility features is very low.

  • Anon (unregistered) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    Nothing wrong with denormalization in the days of 64 bit computing

    Why would denormalizing be a bad decision on a 32 bit processor whereas it would be a fine decision on 64 bit?

  • Bill (unregistered) in reply to Anon
    Anon:
    Mr. AHole DBA:
    Nothing wrong with denormalization in the days of 64 bit computing

    Why would denormalizing be a bad decision on a 32 bit processor whereas it would be a fine decision on 64 bit?

    Because 64 bits is wide enough to hold all those columns (with the right compression).
  • (cs) in reply to Anon
    Anon:
    Mr. AHole DBA:
    Nothing wrong with denormalization in the days of 64 bit computing

    Why would denormalizing be a bad decision on a 32 bit processor whereas it would be a fine decision on 64 bit?

    Are you being pedantic, or you just knew here?

  • Anonypony (unregistered)

    This table must have been designed by the same people who created Salesforce.

    Captcha: luctus - "Resistance be futile." -Luctus of Burg

  • sol (unregistered)

    joins, FK contraints, indexes all that just makes your DB go slow, what they need though is one table with Three columns

    MASTER_CONTROLLER -ID -XML_DATA -RECORD_TYPE

    Record type will of course be hardcoded into no less than 30 files

  • (cs) in reply to snoofle
    snoofle:
    Yes, we have proper source control (translation: defined as copying the entire source tree to another directory and manually migrating changes)
    Alternative translations:

    We have proper source control, but 80% of the devs are located in $thirdWorldCountry, and they don't know how to use it.

    We have many source control systems. The architects use CVS for templates and assorted boilerplate. Development code is stored in git. QA releases code through VSS. Some code is generated automatically from specifications written in Excel spreadsheets; these are kept in our home-brew spec management system...

  • (cs) in reply to nickp
    nickp:
    That's nothing; Wait until you work with a table that has 146 columns, with most of them carrying obsolete or redundant data.

    Why bother with normalization? All those expensive joins!

    Bah I've seen 400+ column tables. Now those REALLY don't perform especially when they are hundreds of millions of rows in the table....

  • (cs)

    I will have denormalized nightmares.

  • Barf 4Eva (unregistered) in reply to faoileag
    faoileag:
    Anonymous Will:
    There is absolutely no way you're going to need 255 characters for a latitude or a longitude. A dozen is quite enough.
    I know. But it doesn't matter, as those 255 characters will not be used.

    Declaring all varchars to be of length 255 may be bad style but has no further implications. Especially not with an explicit column name, that tells what data it stores.

    And of course it is enterprisy. You can pinpoint a position to a hitherto unknown precision of (roughly) 1.1 e-247 m!

    I disagree that it has no further implications. It leads to bad models of what you are trying to describe. Or perhaps allowing representation of values that you deem invalid for some reason or another. By allowing those values, on a large team of people, you can introduce more unknowns in to the workplace.

    Interestingly enough, there are definitely further technical implications as well:

    http://stackoverflow.com/questions/2009694/is-there-an-advantage-to-varchar500-over-varchar8000/5654947#5654947

  • Jibble (unregistered) in reply to Anonymous Will

    [quote user="Anonymous Will"][quote user="faoileag"] There is absolutely no way you're going to need 255 characters for a latitude or a longitude. A dozen is quite enough.[/quote]

    What if you store it as XML?

  • someone (unregistered)

    you are all doing it so horribly wrong. you only need one table with two fields. One named 'key' and one named 'value'. you can save anything!

  • faoileag (unregistered) in reply to snoofle
    snoofle:
    DrPepper:
    Maybe TRWTF is that the hapless employee doesn't have the interviewing skills necessary to determine whether the job is a good one or not, before accepting the offer...
    Sometimes they lie to you during the interview...
    me: How much of the finished product is developed by you? them: Apart from the UI, everything is done inhouse!

    Turned out that "inhouse" in this context meant various subunits distributed all over the country, each specialized in their own respective domain.

    And even at the unit where I (eventually) started, "inhouse" only meant: under the same roof. There was a "core" team and several teams customizing the product for, well, the customers.

    I ended up in one of the teams doing the customizing and was not amused.

    I wouldn't call it an outright lie though, more stretching the truth.

  • faoileag (unregistered) in reply to someone
    someone:
    you are all doing it so horribly wrong. you only need one table with two fields. One named 'key' and one named 'value'. you can save anything!
    Sorry to correct you, but to replace the table shown in the article you need three columns: 'objectid', 'key' and 'value'. And yes, then it is very flexible and future proof. The developers having to use that database will like you!
  • faoileag (unregistered) in reply to Barf 4Eva
    Barf 4Eva:
    faoileag:
    Anonymous Will:
    There is absolutely no way you're going to need 255 characters for a latitude or a longitude. A dozen is quite enough.
    Declaring all varchars to be of length 255 may be bad style but has no further implications.
    Interestingly enough, there are definitely further technical implications as well:

    http://stackoverflow.com/questions/2009694/is-there-an-advantage-to-varchar500-over-varchar8000/5654947#5654947

    Thanks for the link, that stackoverflow post sure makes an interesting read!
  • Jay (unregistered) in reply to anonymous
    anonymous:
    chubertdev:
    Slapout:
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

    You're thinking of "single letter variables", not "single-letter variables."

    At least you're not ranting against them having punctuation out of caps lock.

    Caps lock isn't required for having punctuation. In fact, caps lock has no effect on punctuation (unless you're French).

    Uppercase punctuation sounds like a good thing.

    Dramatic sentences can then end with uppercased exclamation marks, rather than that weak excuse we currently have.

    Only then we can really express how we feel about these lame stories!!!!!!

  • someone (unregistered) in reply to faoileag

    nonsense! the real 'key' field obviously should be a combination of your 'objectid' and 'key' field. one of the nicest features of databases is that you can lump strings together into one field and then have the programmers figure out where one item ends and the next one begins. no need to let the computer worry about that.

  • QJo (unregistered)

    I worked on a system once which was an internal development tool for generation and maintenance of the software which was the business of the company. This tool was written in java, using ejb technology and a swing front end, using a hybrid version of tomcat and jboss, in java 1.4 (it was all fresh and new at the time), and an Oracle database (the latter because we used it for our customer-facing apps). (All attempts to bring it up to version 1.5 of java or higher were met with the brick wall that was the inability to get the chosen configuration to function on anything higher than 1.4)

    This internal development tool was, not to put too fine a point on it, overdesigned from a certain perspective, and horrifically underdesigned from others. The worst immediate bugbear was the one in which the maintenance history of any given customer app was stored on the system in a single VARCHAR(4000) (one for each customer app). All went well till certain mature apps would cause the tool to crash irretrievably when the developer updated that app's details. Yes, it turned out that when the maintenance record exceeded 4000 characters it triggered a SQL exception which was so appallingly handled that it caused all the user's work to be lost since last saving. The solution? "Prune some of the old maintenance history before you start, just in case. Oh, here's a list of those apps whose maintenance record is getting close to the limit. Carry on, folks ..."

    Because of the bureaucracy that had recently been imposed upon the development team (they'd just got ISO 9000), combined with the micromanagement style of the person responsible for this tool, combined with the fact that my predecessor had committed some ill-thought-out and inadequately-tested changes while demob happy, combined with the fact that said predecessor considered documentation for cowards, I was unable to get clearance for the series of changes that I recommended in order to get this appalling heap of metaphorical scrap metal back into a state of adequate functionality. Fortunately I soon found a more rewarding position, and so that contraption lives on, as far as I'm concerned, in my memory only.

  • QJo (unregistered) in reply to chubertdev
    chubertdev:
    Slapout:
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

    You're thinking of "single letter variables", not "single-letter variables."

    At least you're not ranting against them having punctuation out of caps lock.

    A? G! R. O, O K, I C. S. I L F 2 C F U L F T N M N X.

  • Toadworld (unregistered) in reply to QJo

    S, V F X.

  • faoileag (unregistered) in reply to QJo
    QJo:
    "Prune some of the old maintenance history before you start, just in case. Oh, here's a list of those apps whose maintenance record is getting close to the limit." ... I was unable to get clearance for the series of changes that I recommended in order to get this ... into a state of adequate functionality.
    You wanted to fix it properly, didn't you? Like, with another table for the maintenance history and one entry for every change?

    When all you would have to to is create a new column, MaintHistOld = VARCHAR(8000), and then, every time you update the original column by adding X characters, removing those X characters from the beginning of the history string and adding them to MaintHistOld.

    Then, by the time MaintHistOld is full, you have hopefully already left, or, in the best tradition of WTFery, you create MaintHistOldOld = VARCHAR(12000). And shift data twice on each update. ;)

  • faoileag (unregistered) in reply to someone
    someone:
    nonsense! the real 'key' field obviously should be a combination of your 'objectid' and 'key' field. one of the nicest features of databases is that you can lump strings together into one field and then have the programmers figure out where one item ends and the next one begins. no need to let the computer worry about that.
    What worries me is that you are right. Where again did you say you work?
  • someone (unregistered) in reply to faoileag

    now I am at initrode but that code was initechs' baby. Perhaps I should excavate my backup directory see if i can find some entries from those days see if Erik can type some story about a windmill around it.

  • QJo (unregistered) in reply to faoileag
    faoileag:
    QJo:
    "Prune some of the old maintenance history before you start, just in case. Oh, here's a list of those apps whose maintenance record is getting close to the limit." ... I was unable to get clearance for the series of changes that I recommended in order to get this ... into a state of adequate functionality.
    You wanted to fix it properly, didn't you? Like, with another table for the maintenance history and one entry for every change?

    When all you would have to to is create a new column, MaintHistOld = VARCHAR(8000), and then, every time you update the original column by adding X characters, removing those X characters from the beginning of the history string and adding them to MaintHistOld.

    Then, by the time MaintHistOld is full, you have hopefully already left, or, in the best tradition of WTFery, you create MaintHistOldOld = VARCHAR(12000). And shift data twice on each update. ;)

    Oh goodness me, you crack me up!

  • faoileag (unregistered) in reply to QJo
    QJo:
    faoileag:
    Then, by the time MaintHistOld is full, you have ... in the best tradition of WTFery, you create MaintHistOldOld = VARCHAR(12000). And shift data twice on each update. ;)

    Oh goodness me, you crack me up!

    He, he, he. It's "bad solution day". someone started it :)

  • Unique name (unregistered)

    I had a somewhat similar experience at my first job with a table that contained multiple entities. This was convenient [sic] since it was 'easier to load it into the data warehouse'. I needed changes to the data model and I tried to convince the person responsible that I couldn't create foreign key integrity constraints without there being a unique key or a primary key. I just got a blank stare. And we couldn't do any changes to the datamodel anyway because there was no difference between test, quality or production. I WTF'd frequently on that job.

  • (cs) in reply to Ziplodocus
    Ziplodocus:
    The data type usage IS crazy, though. lat and long data stored in a varchar(255), dates stored in a varchar(255). Why not just store the whole lot in one text column, better yet a blob, ooh, ooh no - XML

    As someone else pointed out, the latitude and longitude data might be in raw format and converted later.

    As for the dates, it might be indefinite such as:

    • Winter of 1894-5.
    • March or May 15, 1912 (original label "Ma? 15/12")

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to QJo
    QJo:
    chubertdev:
    Slapout:
    bad legacy code -- single-letter variables

    Discriminating against letter variables because they're not married! And you call yourself progressive.

    You're thinking of "single letter variables", not "single-letter variables."

    At least you're not ranting against them having punctuation out of caps lock.

    A? G! R. O, O K, I C. S. I L F 2 C F U L F T N M N X.

    Did you fall asleep on your keyboard?

  • (cs)

    Hey, I could bet that it was written by my intern at his next job!

    http://forums.thedailywtf.com/forums/p/9973/179888.aspx

Leave a comment on “Multiple Tables!? Why bother?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article