• Frank Cassata (unregistered)

    I do this all the time, XML is the future!

  • Brian Kemp (unregistered)

    I would assume that they're really leveraging the power of XML, all right.

    With the short end of the lever.

  • Miller (unregistered)

    Now I am just a lowly college student with 1 semester worth of database class under my belt, but I can't see why anyone would do this.  Come on, databases are designed to provide quick referencing of information.  How could you search using this system....sigh

    FIRST POST EVER

  • Ametheus (unregistered)

    Obviously, this guy was scared of having two databases.

  • (cs) in reply to Miller

    I applaud this innovative use of modern technology.

  • Dan H. (unregistered)

    The misspelling of Itinerary in the FROM clause doesn't help either...

  • (cs)

    well hey, at least SQL Server 2005 makes all of this XML usage a lot easier...

  • Cam (unregistered) in reply to Matt B

    Why couldn't they just use the OPENXML functionality in SQL 2000?

  • Santxo (unregistered)
    Alex Papadimoulis:

    The database design will be fully extensible. All tables will have only a few columns (such as ID's and created dates), and the rest of the data will be stored in an XML-formatted TEXT column



    Doesn't this kind of "fully extensible database" exist already? Isn't that what they call a filesystem?
  • ServerDude (unregistered)

    I wonder how they'll ever debug and find a bug, when someone comes up with the brillant idea to modify the DTD or XSL of the XML in the table.

    It's like having  a database (without indexes) inside a database - imagine the load of a simple query if the XML is large.


  • Willie (unregistered) in reply to Dan H.
    The misspelling of Itinerary in the FROM clause doesn't help either...

    As long as you mispel consistently.

  • (cs)

    Wow, that must be efficient. What great design.

  • (cs) in reply to Joost_

    On a related note, when is Oracle going to implement XML DOM Level 2? REAL ULTIMATE POWER!

    select XMLDocument.loadXML(table.xml).selectSingleNode('/root/elem['+$id+'][@attr1]').value from mywtftable as table

  • (cs)

    This is an obvious example of improper application layering.

  • toxik (unregistered)

    The intent was probably to parse the XML on the client's side and then read those additional columns...

  • (cs)

    Utter genius this one... he missed out on some more extensibility though - surely each record needs a table ID and a record ID, so you don't have all those pesky tables in the DB, just one big table!

    Slightly more seriously, this issue of easy extensibility comes up more often these days - what are peoples' recommended solutions?

  • zamies (unregistered)

    what a bunch of morons... Anyway they are way ahead of the Flat file comunity...

  • (cs) in reply to zamies

    Goddamn it.

    I LIKE XML. I really do. It has so many uses. But then morons like this come along who think that it solves every problem...Goddamn it! You ALREADY HAVE A RELATIONAL DATABASE. Why do you want to have to add a whole extra set of crap onto it? You'll have to run a sql query, then run the results through an XML parser, then figure out what's going on in the XML with some program logic, then extract the data you want.

    No joins, no fancy sql reporting queries that can save you hundreds of lines of code. No, you get crap. And why? Because you just don't GET IT with regards to XML. If you're sending out a data file to someone, it works a hell of a lot better than CSV, if you're uploading a datafile from someone, it works a hell of a lot better than CSV. If you're just making data publicly available, it works better than putting it in excel, or access, or a text document.

    BUT XML IS NOT A SUBSITUTE FOR A GODDAMN DATABASE!

  • (cs)

    I am certain that the guy who came up with this plan was immediately promoted to management.

  • Fregas (unregistered) in reply to Satanicpuppy

    Satanicpuppy:
    Goddamn it.

    BUT XML IS NOT A SUBSITUTE FOR A GODDAMN DATABASE!

    Amen Amen Amen brother!  halleluja!

  • Fregas (unregistered) in reply to Matt B

    Matt B:
    well hey, at least SQL Server 2005 makes all of this XML usage a lot easier...

    Yes, this will solve all our problems in putting xml into the db.  We no longer will need columsn, other than an XML Data type.  We can put EVERYTHING into one giant xml doc and not have to worry about things like joins, indexes, referential integrity, etc.

  • (cs)

    So, did the company actually pay somebody to come up with this crap?  Good lord, databases exist for a reason.  Please use them properly.

  • Morrolan (unregistered)

    After the WTF, I asked myself, why the INNER JOIN, why not put the test in the where clause?

    Answer: Performance...

    Compound WTF

    Cheers

  • pmagill (unregistered) in reply to dmdietz

    OK! OK! I take it back.  Creative software design is NOT the answer.  Creative software development IS.  Especially when you are handed specifications like today's gem.

  • (cs) in reply to versatilia
    versatilia:

    Slightly more seriously, this issue of easy extensibility comes up more often these days - what are peoples' recommended solutions?


    Uh, tables? You can create as many as you like and each one can contain different information! What's not 'extensible' about that? Why go and recreate the wheel when you have a whole freeking RDBMS at your disposal...
  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    Goddamn it.

    I LIKE XML. I really do. It has so many uses. But then morons like this come along who think that it solves every problem...Goddamn it! You ALREADY HAVE A RELATIONAL DATABASE. Why do you want to have to add a whole extra set of crap onto it? You'll have to run a sql query, then run the results through an XML parser, then figure out what's going on in the XML with some program logic, then extract the data you want.

    No joins, no fancy sql reporting queries that can save you hundreds of lines of code. No, you get crap. And why? Because you just don't GET IT with regards to XML. If you're sending out a data file to someone, it works a hell of a lot better than CSV, if you're uploading a datafile from someone, it works a hell of a lot better than CSV. If you're just making data publicly available, it works better than putting it in excel, or access, or a text document.

    BUT XML IS NOT A SUBSITUTE FOR A GODDAMN DATABASE!
  • (cs) in reply to Fregas

    Yea... I'll be happy not having to worry about RI, FK and the like. But there always be at least 2 things you'd have to JOIN together. And another 2 to UNION. This is the point where guys are sorted out of men and with such great XML technology it will be even harder than now. :D

  • (cs) in reply to tSQL

    stupid editor...

    I just wanted to ditto your

    "BUT XML IS NOT A SUBSTITUTE FOR A GODDAMN DATABASE!"  I don't like XML for the reasons you mentioned.  We have too many developers thinking they aren't getting the job done if they aren't using it.  I had one ding-bat writing some business object to take SQL data and load it into a class.  This meat head decided to take the SQL results, make some XML output and finally got to populating the class! 

  • (cs) in reply to Imroy
    Imroy:
    versatilia:

    Slightly more seriously, this issue of easy extensibility comes up more often these days - what are peoples' recommended solutions?


    Uh, tables? You can create as many as you like and each one can contain different information! What's not 'extensible' about that? Why go and recreate the wheel when you have a whole freeking RDBMS at your disposal...

    And there are schemaless databases out there already for data that cannot easily be forced into tables. Relational databases do not do schemaless very well (searches and so forth), and schemaless databases aren't very good at standard relational tricks of the trade (while searches in amorphous data work much better in a schemaless database than in an RDBMS, they are not fast enough to do indexed JOINs and so forth). Horses for courses and all that....
  • (cs) in reply to Miller

    Maybe they were concerned that their database might become over-normalized.  Everyone knows the danger of an over-normalized database, I'm sure.

  • (cs) in reply to Brian Kemp
    Anonymous:
    I would assume that they're really leveraging the power of XML, all right.

    With the short end of the lever.

    But it is such a powerful approach!  If you can ever get that short end to move, the change on the other end will be huge!

    Yeah, I am being as sarcastic as you were.

    Sincerely,

    Gene Wirchenko

  • (cs)

    SWEET MOTHER OF CHRIST, What are they THINKING?

    I'm sure they are not smart enough to be malicious.  Somebody actually thinks this is a good design.

    But I can foresee that 8 months down the road there will be a follow on project... "For an additional $xxx,xxx dollars, we could seamlessly integrate ALL the data into an 'enterprise class', fully relational database."  (Going to have to really spin that one heavy!)

    Define a structure and rewrite all the source, just to do what they SHOULD have done in the FIRST PLACE!

  • (cs)

    I swear to god, I made a joke about doing just this very thing on Slashdot today.

    My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.

  • Millen (unregistered) in reply to osp70
    osp70:
    I am certain that the guy who came up with this plan was immediately promoted to management.


    The guy who came up with it probably was management.

    It's been my experience that management, more often than not, are the ones trying to use technologies where they're not appropriate.

    My first post ever too...

  • (cs)

    Argh... It's jackholes like this that make it hard for those of us who know how/when to properly use XML to be able to sell using XML to other people.

    I want to use XML in one of my systems. Basically I want to turn our crap server into a webservice, serving XML responses to the clients. This makes the thing easily extensible, it makes us not have to maintain this hideous piece of shit custom server, and it will make the thing far easier to deal with on a regular basis. But no, I get all sorts of shit trying to push that solution because XML has gotten such a bad rap from morons using it in all the wrong places.

  • (cs) in reply to sammybaby
    sammybaby:

    I swear to god, I made a joke about doing just this very thing on Slashdot today.

    My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.



    Ooh, and 2 minutes after I ran out of mod points.
  • (cs) in reply to Cam
    Anonymous:
    Why couldn't they just use the OPENXML functionality in SQL 2000?


    Because then they wouldn't be on TDWTF... Oh wait, they still would..
  • (cs)

    That's okay.  There are a few places here at work where we store serialize()d php arrays in the database.

    Thankfully, we usually never need to deal with them at the SQL level.

  • (cs)

    A wise Chinese man once said: "If you know how to handle a hammer, don't think of everything as a nail...". If you happen to know XML, don't throw XML at everything...  A Chinese man also once said: " Now stop that f*kcing with XML and go work at MacDonalds"...

  • (cs) in reply to Santxo
    Anonymous:

    Doesn't this kind of "fully extensible database" exist already? Isn't that what they call a filesystem?


    I think it's what they call a database.  I don't know of any widely-used relational dbms that doesn't allow you to add columns to existing tables.   You can even remove and modify them.
  • (cs)

      Enron's physical natural gas trading system did something like this. Deals were stored as CLOBS. The reasoning was "We hate our DBAs. This way we can do anything we like." Later, this was widely regarded as a mistake. They ended up supporting two other databases with sane, but slightly different schema so other applications could view their data.

  • (cs) in reply to SurfMan
    SurfMan:
    A Chinese man also once said: " Now stop that f*kcing with XML and go work at MacDonalds"...

    In Soviet China, McDonalds use GoXML at work.
  • (cs) in reply to osp70

    Scarery to think that someone thought this up and multiple people probably approved the concept!

    Talk about layered stupidity!

  • (cs) in reply to trollable

    trollable:
    SurfMan:
    A Chinese man also once said: " Now stop that f*kcing with XML and go work at MacDonalds"...

    In Soviet China, McDonalds use GoXML at work.
    \

    I'll have the GoXML-menu, with mayo, a Attribute-shake, and some Namespace-nachos. To go please....

  • (cs) in reply to Stan Rogers
    Stan Rogers:
    Imroy:
    versatilia:

    Slightly more seriously, this issue of easy extensibility comes up more often these days - what are peoples' recommended solutions?


    Uh, tables? You can create as many as you like and each one can contain different information! What's not 'extensible' about that? Why go and recreate the wheel when you have a whole freeking RDBMS at your disposal...

    And there are schemaless databases out there already for data that cannot easily be forced into tables. Relational databases do not do schemaless very well (searches and so forth), and schemaless databases aren't very good at standard relational tricks of the trade (while searches in amorphous data work much better in a schemaless database than in an RDBMS, they are not fast enough to do indexed JOINs and so forth). Horses for courses and all that....


    Not to be the voice of the Devil, but you can always graft more tables on in a sql solution. There's always some way to relate the data...if only because it's used by the same application. This kind of thing can grow into a monster in a blink, but it's way the hell better than trying to cram lesser datastructures into your database...I've seen people do that kind of stuff to avoid adding two or three tables to a schema that has less than 20 tables already.

    Twenty tables is nothing. Remember the cardinal rule of RDMS...Normalization of Data...You should never ever ever ever have redundant data in your tables. A persons name should be stored in one place, and one place alone. Their birthday, one place. Their street address, one place. Every purchase they've ever made with your system...X entries, 1 table. If you need additional detail that would result in redundant entries, make a new table...Even if it's just a simple lookup table with two columns.

    If your tables start proliferating wildly out of control, or you start having to make wildass queries to get all the data you need in one place, thats a problem. You need to take another look at your schema, make sure your keys are set up intelligently. Sometimes scale will mess with you, and you'll have to age data through adding on more tables to represent different weeks/months/billing years, but that is relatively simple to manage transparently through code (a switch statement will do it, so that the user doesn't have to know that 1995 and 2005 are stored in different tables), and since your keys are the same, you can still query and compare the data with simple, elegant, queries.
  • NacDaddy (unregistered)

    Clearly the problem is all the extra characters in the XML - to much to store.  They clearly should have compressed the XML string to save the space.  [:D]

  • (cs)
    The database design will be fully extensible. All tables will have only a few columns (such as ID's and created dates), and the rest of the data will be stored in an XML-formatted TEXT column

    Arrrrrgh!

    I can't bring myself to read that SQL statement. I see some kind of stuff that must be an attempt at parsing XML within the query, but surely that kind of atrocity does not exist?     :|
  • (cs) in reply to magnus
    magnus:
    sammybaby:

    I swear to god, I made a joke about doing just this very thing on Slashdot today.

    My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.



    Ooh, and 2 minutes after I ran out of mod points.


    Don't worry, I took care of it. =)
  • maht (unregistered)
    Alex Papadimoulis:

    It's a general rule that things will look better on paper then they will when built.



    Hey Alex THAN is a word all by itself.
  • Cowboy Bob (unregistered)

    Someone needs Tamino - http://www2.softwareag.com/Corporate/products/tamino/default.asp

    It's an XML database. Yes I've had the misfortune to use it...

    CAPTCHA : bozo - Hmmm....

Leave a comment on “JOIN ON WTF”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article