JOIN ON WTF

« Return to Article
  • Frank Cassata 2006-02-20 14:14
    I do this all the time, XML is the future!<br>
  • Brian Kemp 2006-02-20 14:15
    <p>I would assume that they're really leveraging the power of XML, all right.</p><p>With the short end of the lever.</p>
  • Miller 2006-02-20 14:16
    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<br><br>FIRST POST EVER<br>
  • Ametheus 2006-02-20 14:18
    Obviously, this guy was scared of having two databases.<br>
  • Joost_ 2006-02-20 14:19
    I applaud this innovative use of modern technology.
  • Dan H. 2006-02-20 14:23
    The misspelling of Itinerary in the FROM clause doesn't help either...
  • Matt B 2006-02-20 14:25
    well hey, at least SQL Server 2005 makes all of this XML usage a lot easier...<br>
  • Cam 2006-02-20 14:26
    Why couldn't they just use the OPENXML functionality in SQL 2000?
  • Santxo 2006-02-20 14:26
    Alex Papadimoulis:

    <p><i>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</i></p>
    <br><br>Doesn't this kind of "fully extensible database" exist already? Isn't that what they call a filesystem?<br>
  • ServerDude 2006-02-20 14:27
    I wonder how they'll ever debug and find a bug, when someone comes up with the <span style="font-weight: bold;">brillant</span> idea to modify the DTD or XSL of the XML in the table.<br><br>It's like having  a database (without indexes) inside a database - imagine the load of a simple query if the XML is large. <br><br><br>
  • Willie 2006-02-20 14:28
    <blockquote>
    The misspelling of Itinerary in the FROM clause doesn't help either...
    </blockquote>

    As long as you mispel consistently.

  • toddhilehoffer 2006-02-20 14:28
    Wow, that must be efficient. What great design.
  • Joost_ 2006-02-20 14:29
    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
  • retnuh 2006-02-20 14:30
    This is an obvious example of improper application layering.
  • toxik 2006-02-20 14:31
    The intent was probably to parse the XML on the client's side and then read those additional columns...<br>
  • versatilia 2006-02-20 14:31
    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!<br>
    <br>
    Slightly more seriously, this issue of easy extensibility comes up more
    often these days - what are peoples' recommended solutions?<br>
    <br>
  • zamies 2006-02-20 14:35
    what a bunch of morons... Anyway they are way ahead of the Flat file comunity...<br><br>
  • Satanicpuppy 2006-02-20 14:46
    Goddamn it.<br><br>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.<br><br>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.<br><br>BUT XML IS NOT A SUBSITUTE FOR A GODDAMN DATABASE!<br>
  • osp70 2006-02-20 14:47
    I am certain that the guy who came up with this plan was immediately promoted to management.
  • Fregas 2006-02-20 14:59
    <P>
    Satanicpuppy:
    Goddamn it.<BR><BR>BUT XML IS NOT A SUBSITUTE FOR A GODDAMN DATABASE!<BR>
    </P>
    <P>Amen Amen Amen brother!&nbsp; halleluja!</P>
  • Fregas 2006-02-20 15:03
    <P>
    Matt B:
    well hey, at least SQL Server 2005 makes all of this XML usage a lot easier...<BR>
    </P>
    <P>Yes, this will solve all our problems in putting xml into the db.&nbsp; We no longer will need columsn, other than an XML Data type.&nbsp; We can put EVERYTHING into one giant xml doc and not have to worry about things like joins, indexes, referential integrity, etc.</P>
  • dmdietz 2006-02-20 15:07
    So, did the company actually pay somebody to come up with this crap?&nbsp; Good lord, databases exist for a reason.&nbsp; Please use them properly.<br>
  • Morrolan 2006-02-20 15:09
    <P>After the WTF, I asked myself, why the INNER JOIN, why not put the test in the where clause?</P>
    <P>Answer: Performance...</P>
    <P>Compound WTF</P>
    <P>Cheers</P>
  • pmagill 2006-02-20 15:10
    OK! OK! I take it back.&nbsp; Creative software design is NOT the answer.&nbsp; Creative software development IS.&nbsp; Especially when you are handed specifications like today's gem.<br>
  • Imroy 2006-02-20 15:12
    versatilia:
    <br>
    Slightly more seriously, this issue of easy extensibility comes up more
    often these days - what are peoples' recommended solutions?<br>
    <br><br>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...<br>
  • tSQL 2006-02-20 15:15
    Satanicpuppy:
    Goddamn it.<BR><BR>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.<BR><BR>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.<BR><BR>BUT XML IS NOT A SUBSITUTE FOR A GODDAMN DATABASE!<BR>
  • zgoda 2006-02-20 15:17
    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
  • tSQL 2006-02-20 15:19
    <P>stupid editor... </P>
    <P>I just wanted to ditto your</P>
    <P>"BUT XML IS NOT A SUBSTITUTE FOR A GODDAMN DATABASE!"&nbsp; I don't like XML for the reasons you mentioned.&nbsp; We have too many developers thinking they aren't getting the job done if they aren't using it.&nbsp; I had one ding-bat writing some business object to take SQL data and load it into a class.&nbsp; This meat head decided to take the SQL results, make some XML output and finally got to populating the class!&nbsp; </P>
  • Stan Rogers 2006-02-20 15:20
    Imroy:
    versatilia:
    <br>
    Slightly more seriously, this issue of easy extensibility comes up more
    often these days - what are peoples' recommended solutions?<br>
    <br><br>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...<br>
    <br>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....<br>
  • GalacticCowboy 2006-02-20 15:21
    Maybe they were concerned that their database might become over-normalized.&nbsp; <STRONG>Everyone</STRONG> knows the danger of an over-normalized database, I'm sure.
  • Gene Wirchenko 2006-02-20 15:25
    Anonymous:
    I would assume that they're really leveraging the power of XML, all right.<p>With the short end of the lever.
    </p>But it is such a powerful approach!&nbsp; If you can ever get that short end to move, the change on the other end will be huge!<br><br>Yeah, I am being as sarcastic as you were.<br><br>Sincerely,<br><br>Gene Wirchenko<br><br>
  • marvin_rabbit 2006-02-20 15:29
    SWEET MOTHER OF CHRIST, What are they THINKING?<br><br>I'm sure they are not smart enough to be malicious.&nbsp; Somebody actually thinks this is a good design.<br><br>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."&nbsp; (Going to have to really spin that one heavy!)<br><br>Define a structure and rewrite all the source, just to do what they SHOULD have done in the FIRST PLACE!<br>
  • sammybaby 2006-02-20 15:34
    <P>I swear to god, I made a joke about doing just this very thing <A href="http://slashdot.org/comments.pl?sid=177985&amp;cid=14762697">on Slashdot today</A>.</P>
    <P>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</P>
  • Millen 2006-02-20 15:34
    osp70:
    I am certain that the guy who came up with this plan was immediately promoted to management.
    <br><br>

    The guy who came up with it probably was management.<br><br>

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

    My first post ever too...
  • Otto 2006-02-20 15:38
    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.<br><br>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.<br><br>
  • magnus 2006-02-20 15:45
    sammybaby:
    <p>I swear to god, I made a joke about doing just this very thing <a href="http://slashdot.org/comments.pl?sid=177985&amp;cid=14762697">on Slashdot today</a>.</p>
    <p>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</p>
    <br><br>Ooh, and 2 minutes after I ran out of mod points.<br>
  • hash 2006-02-20 15:46
    Anonymous:
    Why couldn't they just use the OPENXML functionality in SQL 2000?
    <br><br>Because then they wouldn't be on TDWTF... Oh wait, they still would..<br>
  • merreborn 2006-02-20 15:52
    That's okay.&nbsp; There are a few places here at work where we store serialize()d php arrays in the database.<br><br>Thankfully, we usually never need to deal with them at the SQL level.<br>
  • SurfMan 2006-02-20 15:53
    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...&nbsp; A Chinese man also once said: " Now stop that f*kcing with XML and go work at MacDonalds"...<br>
  • Suck My Lisp 2006-02-20 16:06
    Anonymous:
    <br>Doesn't this kind of "fully extensible database" exist already? Isn't that what they call a filesystem?
    <br>
    <br>
    I think it's what they call a database.&nbsp; I don't know of any
    widely-used relational dbms that doesn't allow you to add columns to
    existing tables.&nbsp;&nbsp; You can even remove and modify them.<br>
  • mpswaim 2006-02-20 16:08
    &nbsp; 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&nbsp;schema so other applications could view their data.
  • trollable 2006-02-20 16:10
    SurfMan:
    A Chinese man also once said: " Now stop that f*kcing with XML and go work at MacDonalds"...
    <br>In Soviet China, McDonalds use GoXML at work.<br>
  • sgrieger 2006-02-20 16:19
    <P>Scarery to think that someone thought this up and multiple people probably approved the concept!</P>
    <P>Talk about layered stupidity!</P>
  • SurfMan 2006-02-20 16:21
    <P>
    trollable:
    SurfMan:
    A Chinese man also once said: " Now stop that f*kcing with XML and go work at MacDonalds"...
    <BR>In Soviet China, McDonalds use GoXML at work.<BR>
    \</P>
    <P>I'll have the GoXML-menu, with mayo, a Attribute-shake, and some Namespace-nachos. To go please....</P>
  • Satanicpuppy 2006-02-20 16:28
    Stan Rogers:
    Imroy:
    versatilia:
    <br>
    Slightly more seriously, this issue of easy extensibility comes up more
    often these days - what are peoples' recommended solutions?<br>
    <br><br>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...<br>
    <br>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....<br>
    <br><br>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. <br><br>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.<br><br>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.<br>
  • NacDaddy 2006-02-20 16:29
    Clearly the problem is all the extra characters in the XML - to much to store.&nbsp; They clearly should have compressed the XML string to save the space.&nbsp; [:D]
  • Arancaytar 2006-02-20 16:29
    <div style="margin-left: 40px;"><span id="_ctl0_PostForm_Reply"><i>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</i></span><br><span id="_ctl0_PostForm_Reply"></span></div><span id="_ctl0_PostForm_Reply"><i><br></i>Arrrrrgh!<br><br>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? </span><a href="">:|</a>
  • Satanicpuppy 2006-02-20 16:34
    magnus:
    sammybaby:
    <p>I swear to god, I made a joke about doing just this very thing <a href="http://slashdot.org/comments.pl?sid=177985&amp;cid=14762697">on Slashdot today</a>.</p>
    <p>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</p>
    <br><br>Ooh, and 2 minutes after I ran out of mod points.<br>
    <br><br>Don't worry, I took care of it. =)<br>
  • maht 2006-02-20 17:04
    Alex Papadimoulis:
    <p>It's a general rule that things will look better on paper <span style="font-weight: bold;">then</span> they will when built. </p>
    <br><br>Hey Alex THAN is a word all by itself.<br>
  • Cowboy Bob 2006-02-20 17:24
    Someone needs Tamino - http://www2.softwareag.com/Corporate/products/tamino/default.asp<br>
    <br>
    It's an XML database. Yes I've had the misfortune to use it...<br>
    <br>
    CAPTCHA : bozo - Hmmm....<br>
  • Jebas 2006-02-20 17:41
    Notice mysql (5.1) now has ExtractValue() and UpdateXML() to performan xpath queries and updates on xml documents stored in text fields. Can't wait to see some of the gems this will inevitably result in...<br><br>Personally, I think storing xml in a relational database is a very bad idea, unless that database is specifically designed to handle xml (ie, <span class="topstoryhead">Oracle's XML DB </span>). I reckon it probably comes down to developers being too lazy to design a proper schema for their tables - whatever the reason, it leaves a freakin mess behind for those attempting to maintain the damn thing.<br><br>
  • masklinn 2006-02-20 17:46
    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

    <p>Actually, they'll probably use that XQuery bullshit, the wonderful Tamino database already does it (native XML database for the win, XQuery or XQL requests (with heaps of XPath goodness... the parts that've been implemented in the DB engine i mean), runs slower than molasses and overall defeats the very purpose of a database).</p>
    <p>But at least you can run XSLs on the raw data you retrieve from the DB without having to do any transformation!</p>
    Anonymous:
    Someone needs Tamino - http://www2.softwareag.com/Corporate/products/tamino/default.asp<br>
    <br>
    It's an XML database. Yes I've had the misfortune to use it...<br>
    <br>
    CAPTCHA : bozo - Hmmm....<br>

    <p>Oooh, another guy who's had the (dubious) priviledge of "using" Tamino, I'm not alone!</p>
  • John Smallberries 2006-02-20 17:55
    Imroy:
    versatilia:
    <br>
    Slightly more seriously, this issue of easy extensibility comes up more
    often these days - what are peoples' recommended solutions?<br>
    <br><br>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...<br>
    <br>Uh, no. Nice sarcasm &amp; spelling, though.<br><br>Are you going to let your users specify new schema elements, and are you going to design a front end app to do so? I thought not.<br><br>By "extensible", I'm guessing they mean extensible at <span style="font-style: italic;">run time</span>, ad hoc, by the users. I've worked on a number of systems where this was a requirement and it's always very difficult. The best solution I found was to create an abstract db schema. This is difficult, but has the advantages of leaving the data in native, non-compound db attributes (unlike today's example).<br>
  • Anon 2006-02-20 18:03
    I'm actually working on fixing something very similiar.<br><br>XML doesn't hurt applications. Developers hurt applications.<br>
  • TB 2006-02-20 18:15
    I inherited a project that has a database that stores most of the data in xml strings. Aside from the pain of extracting data, another WTF is that the storage required for a piece of data like UsersMiddleInitial, which could be captured in a char(1) column, you store it as <UsersMiddleInitial>J</UsersMiddleInitial> in each and every column.

    Probably an outsourcing nightmare like the system I deal with.
  • paddy 2006-02-20 18:28
    This is absolutely evil.&nbsp; My guess is either management kept
    changing the requirements, or the programmers never realized what they
    needed to do, and in previous projects, they felt like they were always
    mucking with changing the database table structures all the time to
    handle design refinements.&nbsp; <br>
    <br>
    Maybe they could make classes "fully extensible" by just using
    hashtables of strings and function pointers...it seems like "fully
    extensible" is another way of saying "won't have to adhere to pesky
    advanced plannning"&nbsp; and such.<br>
    <br>
    <br>
    Btw, how do I apply to become a hardware vendor for this company?&nbsp;
    I foresee brisk sales of large load balancing database server arrays.<br>
  • Dreddlox 2006-02-20 18:31
    Thats...not really that bad...<br>Seriously, I've done far worse things in SQL and I've known the language less than 3 months<br>Try UNIONing 3 statements each 6 lines long, reading from tables with different column names for the same data and each statement requiring 2 SELECTs in their FROM list because the unindexed lookup table otherwise gets overly linked and sends the execution time to hell... That statement only reached 3 SELECTs deep(the third was so that I could order the whole lot) and I found it relatively easy to maintain weeks after I had written it.<br><br>If you think SQL is bad, try dealing with VB... The only reason my statement was so long was because it'd be agonizing to bring the data back and do all the transformation on the local computer in Excel for Applications... -.-'<br>
  • Dick Cheney 2006-02-20 19:14
    sammybaby:
    <p>I swear to god, I made a joke about doing just this very thing <a href="http://slashdot.org/comments.pl?sid=177985&cid=14762697">on Slashdot today</a>.</p>
    <p>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</p>
    <br><br>Oh no, you've just WTF'd Slashdot with that link!<br>
  • My name might be Jim 2006-02-20 20:17
    <P>Once again we are presented evidence of people who should simply not be in our business.</P>
    <P>This one is off the charts, though.</P>
  • Stan Rogers 2006-02-20 20:18
    Satanicpuppy:
    Stan Rogers:
    Imroy:
    versatilia:
    <br>
    Slightly more seriously, this issue of easy extensibility comes up more
    often these days - what are peoples' recommended solutions?<br>
    <br><br>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...<br>
    <br>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....<br>
    <br><br>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. <br><br>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.<br><br>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.<br>
    <br><br>That's just about the opposite of what a schemaless database provides. With any relational database, there needs to be some commonality (other than "housekeeping metadata") between entries/rows/records. Not every record may produce entries in every table, but when the data are truly amorphous, one may need essentially one table per record/entry/document. Yes, potentially thousands or millions of tables in a single database. In a schemaless database, only the metadata is guaranteed. All data, though, remain retrievable/searchable by field, even if that field may exist in only one or two entries of several million. Again, it's horses for courses.<br>
  • nathan 2006-02-20 20:39
    <span id="PostFlatView">Ok, here's my beef.  Some people here are
    saying, "XML is great when used for the right purposes"...maybe
    so.  Although for basic data, why not use something more
    lightweight, like JSON?  XML is really bloated, and the model of
    having attributes and a body doesn't really map all that well to an
    object model.  JSON does.<br>
    <br>
    For markup of text, XML is great.  And hey, wait a minute, that's
    what it was designed for!  Extensible MARKUP language.  Not
    extensible all-purpose data language.  MARKUP.  It's like
    HTML, only you can define your own tags.  Who would think that
    HTML is a good format for sending or storing raw data?  But that's
    what the world is doing now.  <br>
    <br>
    So repeat after me:  XML is for MARKUP.  Not for structured
    data.  Something like JSON does structured data much better...more
    readably, more compactly, more logically, easier to parse.<br></span>
  • R.Flowers 2006-02-20 20:54
    Anonymous:
    sammybaby:

    <P>I swear to god, I made a joke about doing just this very thing <A href="http://slashdot.org/comments.pl?sid=177985&amp;cid=14762697">on Slashdot today</A>.</P>
    <P>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</P>
    <P>
    <BR><BR>Oh no, you've just WTF'd Slashdot with that link!<BR>
    </P>
    <P>Heh. There was a <A href="http://www.techeblog.com/index.php/tech-gadget/top-10-strangest-mp3-players">website</A>* that was posted on both the frontpages of <A href="http://hardware.slashdot.org/article.pl?sid=06/02/20/1344202">Slashdot</A> and <A href="http://www.digg.com/links/Top_10_Strangest_MP3_Players">digg.com</A> today. Poor bastard never had a chance...</P>
    <P>* <FONT color=#808080><SMALL>Aint I a stinker? Of course, I don't think WTF's effect will be nearly as bad...</SMALL></FONT></P>
  • R.Flowers 2006-02-20 20:55
    <P>
    R.Flowers:
    * <FONT color=#808080><SMALL>Aint I a stinker? Of course, I don't think WTF's effect will be nearly as bad...</SMALL></FONT>
    </P>
    <P>&nbsp;</P>
    <P>Oh, that's right. <FONT size=1>SMALL</FONT> means <FONT size=6>VERY,&nbsp; VERY FRIGGIN' BIG!!!</FONT></P>
  • vDave420 2006-02-20 21:36
    magnus:
    sammybaby:
    <p>I swear to god, I made a joke about doing just this very thing <a href="http://slashdot.org/comments.pl?sid=177985&amp;cid=14762697">on Slashdot today</a>.</p>
    <p>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</p>
    <br><br>Ooh, and 2 minutes after I ran out of mod points.<br>
    <br><br>That's ok, I hit him a +1 myself.<br><br>&nbsp; -dave-<br>
  • TheDauthi 2006-02-20 21:42
    I've seen worse than this.&nbsp; I've got a WTF that I've got to submit in the near future [as soon as I can get enough of the business logic that is owned by my company out, it's been OK'ed] where the guy invented his own format to put inside a column.&nbsp; I can't decide if the best part about it is that he actually had some of the columns to use in the same table or that he does SQL queries parsing the data, or if it's that the whole thing fails if you have a tilde out of place...
  • Jenny Talia 2006-02-20 22:26
    Stan Rogers:
    <br>schemaless<br>
    <br><br>When I first read that word, I saw "shemales", heehee!<br><br>
  • Spartacus 2006-02-20 23:25
    Holy shit. This is possibly the worst thing I have ever seen. I congratulate the programmers on their pure evilness.<br>
  • felix 2006-02-21 00:25
    Anonymous:
    <span id="PostFlatView"> Something like JSON does structured data much better...more
    readably, more compactly, more logically, easier to parse.<br></span>
    <br>
    <br>
    Yeah... Or Lua... Heck, even the PHP serialization format is readable
    enough and compact enough. As they say, there are only solutions...<br>
    <br>
    The real trouble is, you can't search/join on a column containing <span style="font-style: italic;">that</span>.
    Not from SQL. Not if you want something resembling decent performance.
    But then again, SQL is even more misunderstood and misused that XML...<br>
    <br>
  • greyfade 2006-02-21 02:16
    this reminds me of a query i wrote some time ago.  i'm rather morbidly proud of it despite its complexity:  7 left joins on a well-designed database for event listings.  interestingly, my query managed to properly locate, sort, and post-process a list of the week's upcoming eventsand arranged them appropriately for publication in a local newspaper.<br><br>it only required a couple lines of PHP to split the data by section and sort those arbitrarily, but the data, as produced, was perfect for the paper's needs.<br><br>i wish i could find the final query i came up with...  it was a doozy weighing in at over 8,000 bytes.<br>
  • Anonymouse 2006-02-21 03:04
    That's like taking all the good parts of both SQL and XML and combining
    them... and then throwing them out of the window and make do with
    what's left over.<br>
  • Mr Reuben Red 2006-02-21 03:11
    tSQL:
    <p>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!  </p>
    <br><br>Working on something similar here.<br>I'm trying to find out why one of the linux machines on our network is so sluggish in the morning, and OK for the rest of the day. Turns out that box was selected to run a particular cron job at 3am, which imports new data from a certain source into the database. Turns out that its method for doing this is to get the files (a numbered set of a few hundred CSV files), slurp them all into memory, sort them, write them out to a numbered set of XML files, then spawn another process which reads in the XML files, checks them for validity and combines them into one large file. It then reads in and parses this file, sorts it several times to check for duplicates on several different unique fields (rewriting and re-parsing the file on disk each time), before finally breaking the data down into a big set of parallel arrays, which it loops over to insert the data into the SQL database.<br><br>Result: Transferring ~5000 rows of 31 fields from CSV files to an SQL table takes 99% CPU and ~250MB of ram, for about 10-12 hours every morning. Aaaaargh!<br>Stripping out all the XML crap reduces this execution time to just over 6 minutes (most of which is spent waiting for the files to arrive)<br>
  • Grasshopper 2006-02-21 04:05
    <P>Why not store all of the critical, permanent fields in one table and secure it in the rdbms&nbsp;to prevent any modification. Then create another related table to store the 'optional' columns, and build a nice, safe data layer component&nbsp;to control addition of new columns to this secondary table? </P>
    <P>It would then be possible to set the right data type &amp; size for each additional column, and&nbsp;use simple sql syntax to retreive data, rather than parse all of that XML.</P>
    <P>Just a thought....any feedback?&nbsp;Am I setting up a future&nbsp;WTF with this idea??? </P>
  • pf 2006-02-21 05:27
    <P><FONT face=Verdana size=2>I think this thing is somewhere between Commerce Server ("The database design will be fully extensible") and BizTalk "the rest of the data will be stored in an XML-formatted TEXT column" [:D] [:D]</FONT></P>
    <P><FONT face=Verdana size=2>pf</FONT></P>
  • Tragomaskhalos 2006-02-21 05:46
    <P>What I also love is the way that performance will slowly degrade as more data is added (because the database hasn't got a cat in hell's chance of indexing this monstrosity), by which time presumably the app will be live or near-live and re-engineering it to do things properly is going to be an enormous task. Mazeltov !</P>
    <P>&nbsp;</P>
  • darjien 2006-02-21 05:57
    Anonymous:
    Clearly the problem is all the extra characters in the XML - to much to store.&nbsp; They clearly should have compressed the XML string to save the space.&nbsp; [:D]
    <br><br>Now if only I didn't have an existing system in production for several clients that did just that :(<br><br>I work for one of the world's larger ISP/CPs - and I was involved in writing a system that provides pdfs that are produced on the fly using XSLT for a few million end users. For reasons of data integrity (the PDFs can't change) we decided to store the XML directly, rather than generating it from potentially malleable tables.<br><br>We're now migrating everything, for different, but still slightly insane, business reasons to storing the PDFs in the database. Even more joy.<br><br>darjien<br>
  • Klaus 2006-02-21 06:12
    My eyes! The googles, they do nothing!<br>
  • Adolf 2006-02-21 06:34
    Otto:
    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.<br>
    <br><br>You're a fag.<br><br>And what would be this mystical "properly use" of XML that you are so keen on using?<br><br>Fucking poser.<br><br>Ass-monkey.<br>
  • Joost_ 2006-02-21 07:10
    I made an application for a guy that needs to send a few reports - basically just some weirdly laid-out <table>s - to the authorities every few days. He used to do it all by hand. I store the data he needs to fill in in an XML file, then use XSLT to actually generate the HTML reports (used to be Microsoft .DOC) and these get e-mailed to the authorities. As an added bonus, he saves minutes of satellite time because HTML is so much smaller than Word.

    INI files would have been underpowered, SQL would have been overkill. I'd say this is an example of proper use of XML.
  • ParkinT 2006-02-21 07:25
    <P>
    versatilia:
    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!<BR><BR>Slightly more seriously, this issue of easy extensibility comes up more often these days - what are peoples' recommended solutions?<BR><BR>
    </P>
    <P>As the coder (internally or as a consultant), your presence is the extensibility.&nbsp; Mo' money, mo' money.</P>
  • Isvara 2006-02-21 07:37
    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
    <br><br>Sleepycat have a native XML database. Oracle have just bought Sleepycat. So perhaps we'll see.<br><br>
  • johnl 2006-02-21 08:05
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">And what would be this mystical "properly use" of XML that you are so keen on using?</span><br><br>Persisting complex objects in a text format, either for local storage or transmission to another system?&nbsp; Import/Export to/from databases?&nbsp; Displaying data on a web page (using XSLT)?&nbsp; AJAX?&nbsp; Event logging? (Yes, you read that last one right - just try setting up a CI environment with tools that don't support XML logging, and you'll see what I mean)<br><br>Perhaps there are better ways of doing it, but XML's power comes from the fact that it is widely accepted and, despite the anti-xml pseudo-religious cult that seems to be popular around here, it works.&nbsp; It does the job well enough that I don't see the need to force everyone to change to yet another format, even if that other format is actually better.&nbsp; XML came along when the only alternatives were CSV, which simply doesn't do the job if the data is anything other than a single table.<br><br>Someone mentioned JSON.&nbsp; I've never heard of JSON before now, and I doubt many other people have either.&nbsp; So why should I spend a lot of time implementing JSON into my application as, say an export format, when no-one can import it?<br></span>
  • TheRider 2006-02-21 08:09
    Anonymous:
    Stan Rogers:
    <br>schemaless<br>
    <br><br>When I first read that word, I saw "shemales", heehee!<br><br>
    <br><br>This is all so shameless<br>
  • davesag 2006-02-21 08:47
    At the last place I worked their 'developers' (management had outsourced to el-cheapo workers in the USA, who in turn outsourced to cheaper workers in bulgaria) had done pretty much exactly that. Their app was both client side java swing and server side java running in some borland 'enterprise' server with ms-sql behind it. on the client side they use a custom persistance scheme to map the data to xml and then write that into an embedded database. on the server they wrote a subtly different xml to ms-sql.

    and they complained it was too slow.

    but the best / worst thing was they were not doing any of their db stuff wrapped in any sort of transactions and so during a typical step such as:

    save meta-data
    save image
    generate image thumbnail
    save thumb

    if the generate thumb step broke (and it did cos they hadn't worked out how to use JAI properly) the thumbs were never saved and the app seemed to be losing people's pictures.

    sorry i seemed to veer off topic a bit there but yeah - xml as a longtext in a sql table is just stupid.
  • Jeff S 2006-02-21 08:57
    Actually, like most everything else, it all depends.<br><br>This example clearly shows that the XML consists of *data* that should be stored in the database tables, since it is being joined and searched on and the like.&nbsp; But the if the XML content is truly just a *single value* that is being stored, then it is no different than storing any other text in a database column.<br><br>The key is, are you putting a square peg in a round hole (as in this example), or do you simply need to store a snippet of XML for a set of entities in your data?&nbsp; The act of storing some text in an XML format in your database doesn't really break any rules, but trying to search, sort, or join to it using SQL is what makes this a WTF.<br>
  • Alex Papadimoulis 2006-02-21 09:16
    <P>
    johnl:
    <SPAN id=_ctl0_PostForm_Reply>XML's power comes from the fact that it is widely accepted and, despite the anti-xml pseudo-religious cult that seems to be popular around here, it <SPAN>works. </SPAN>
    </SPAN></P>
    <P><SPAN>As a patron member of said cult, I should note that this is the *only* thing that gives XML its power. I should also note that "works" is a pretty low standard - I could base a data-exchange language on Microsoft Word, and that would still work.</SPAN></P>
    <P><SPAN>
    johnl:
    XML came along when the only alternatives were CSV
    </SPAN></P>
    <P><SPAN>There have been better alternatives to XML long before XML came around. Let us remember that XML post-dates HTML; it is, after all based on HTML (get the comment on MS Word above, they're both display documents?). Revisionist historians will tell you that "oh no, XML is a branch of SGML" -- but seriously folks, look at HTML. Then look at XML. Then look at SGL. It's pretty clear who's a child of whom.</SPAN></P>
  • Erik 2006-02-21 09:26
    <P>
    Anonymous:
    Why couldn't they just use the OPENXML functionality in SQL 2000?
    </P>
    <P>Is it possible they aren't using SQL Server 2000?</P>
  • bob 2006-02-21 10:05
    This is another unfortunate case of people who aren't comfortable with DB's or are "developers" but don't know databases well. <br><br>As another poster stated, this is more modern "flat-file" way of "structuring" your database.<br><br>I'm going to bet too, that since the SQL is so attrocious, that the deadlines were blown and other developers resorted to selecting as much of the table as required and processing it in local code as opposed to just getting what they needed via SQL.<br><br>When are people going to learn?<br><br><br>
  • johnl 2006-02-21 10:27
    <p><span><span style="font-style: italic;">As a patron member of said
    cult, I should note that this is the *only* thing that gives XML its
    power. </span><br></span></p><p><span>Indeed, I agree with that.&nbsp; But you can't argue that that power exists, it exists for a reason, and that at the moment there's nothing else that has that property.&nbsp; Ok, maybe CSV, but that can't handle anything more complex than a single table.<br></span></p><p style="font-style: italic;"><span>I should also note that "works" is a pretty low standard - I
    could base a data-exchange language on Microsoft Word, and that would
    still work.</span></p><p>Not without giving up a lot of functionality - just being plain text has a lot going for it, you know.&nbsp; I agree, it is a fairly low standard, and no-one's claiming that XML's perfect, or that if it was all done again, it might be done differently.</p><p><span><blockquote></blockquote></span></p>
    <p style="font-style: italic;"><span>There have been better alternatives to XML long before XML
    came around. Let us remember that XML post-dates HTML; it is, after all
    based on HTML (get the comment on MS Word above, they're both display
    documents?). <br></span></p><p><span>Not quite...&nbsp; XML shares syntactical style with HTML, but that does not mean it's a direct descendant, more of a younger sibling.&nbsp; <br></span></p>Name some superior alternatives to XML that were around before XML came on the scene, and we can tell you why we're using XML rather than those alternatives.&nbsp; Even if that's just because no-one knew about the alternative (see my comment on JSON)<br>
  • masklinn 2006-02-21 10:45
    Alex Papadimoulis:
    it is, after all based on HTML

    <p>no</p>
    Alex Papadimoulis:
    look at HTML

    <p>Fully defined and specified special-purpose (DSL) markup language, SGML application</p>
    Alex Papadimoulis:
    Then look at XML.

    <p>A metalanguage or a general purpose markup language used to create special-purpose language</p>
    Alex Papadimoulis:
    Then look at SGML.

    <p>A metalanguage or a general purpose markup language used to create special-purpose language</p>
    Alex Papadimoulis:
    It's pretty clear who's a child of whom.

    <p>XML is not a child, it's a giant step.</p>
  • stevekj 2006-02-21 10:54
    Alex Papadimoulis:
    <pre><font color="#000099">SELECT</font> H.Id, H.XmlData, I.XmlData
    <font color="#000099">FROM</font> IteneraryItems I <font color="#000099">INNER JOIN </font>
    Hotels H <font color="#000099">ON
    CONVERT</font>(
    <font color="#000099">INT</font>
    ,<font color="#000099">SUBSTRING</font>(
    <font color="#000099">CONVERT</font> (<font color="#000099">VARCHAR</font>, I.XmlData)
    ,<font color="#000099">PATINDEX</font>(<font color="#990000">'%<var name="" hotelid=""><string>%'</string></var></font>, I.XmlData) + 28
    ,<font color="#000099">PATINDEX</font>(
    <font color="#990000">'%%'</font>
    ,<font color="#000099">SUBSTRING</font>(
    <font color="#000099">CONVERT</font> (<font color="#000099">VARCHAR</font>, I.XmlData)
    ,<font color="#000099">PATINDEX</font>(<font color="#990000">'%<var name="" hotelid=""><string>%'</string></var></font>, I.XmlData) + 28
    ,25)
    ) - 1
    )) = H.Id
    <font color="#000099">WHERE</font> I.IsDeleted = 0
    <font color="#000099">AND PATINDEX</font>(<font color="#990000">'%<var name="" hotelid=""><string>%'</string></var></font>, I.XmlData) &gt; 0
    <font color="#000099">AND</font> I.CreatedDate <font color="#000099">BETWEEN</font> @StartDate <font color="#000099">AND</font> @EndDate</pre>
    <br><br>Wow, I'm not even a database guy and this <span style="font-style: italic;">still </span>makes my eyes bleed!<br><br>
  • nonametoday 2006-02-21 11:02
    For you it's a fucking joke and I actually had to fight a consequences of someone hearing similar joke and deciding it's a great idea... No, really. Having some DBA expertise, I almost had a heart attack on the spot. The scariest part - it was advocated by two guys calling themselves architects. Yes, just to confirm, I'm talking about saving serialized objects to the SQL Server ntext column. Luckily, I won that fight, but I don't know what's next they're gonna come up with. <br>
  • PKman 2006-02-21 11:28
    johnl:
    <p><span><span style="font-style: italic;">As a patron member of said
    cult, I should note that this is the *only* thing that gives XML its
    power. </span><br></span></p><p><span>Indeed, I agree with that.  But you can't argue that that power exists, it exists for a reason, and that at the moment there's nothing else that has that property.  Ok, maybe CSV, but that can't handle anything more complex than a single table.<br></span></p><p style="font-style: italic;"><span>I should also note that "works" is a pretty low standard - I
    could base a data-exchange language on Microsoft Word, and that would
    still work.</span></p><p>Not without giving up a lot of functionality - just being plain text has a lot going for it, you know.  I agree, it is a fairly low standard, and no-one's claiming that XML's perfect, or that if it was all done again, it might be done differently.</p><p><span><blockquote></blockquote></span></p>
    <p style="font-style: italic;"><span>There have been better alternatives to XML long before XML
    came around. Let us remember that XML post-dates HTML; it is, after all
    based on HTML (get the comment on MS Word above, they're both display
    documents?). <br></span></p><p><span>Not quite...  XML shares syntactical style with HTML, but that does not mean it's a direct descendant, more of a younger sibling.  <br></span></p>Name some superior alternatives to XML that were around before XML came on the scene, and we can tell you why we're using XML rather than those alternatives.  Even if that's just because no-one knew about the alternative (see my comment on JSON)<br>
    <br><br>Sheesh. . .<br><br>CSV was a good idea before PKZip came along.<br><br>XML could not survive without something like PKZip.<br><br>XML has served to create a need for humungous disk drives. . .   lots of memory for parsers to "work".    For providing a standardizable way of presenting data for printing i.e., Markup  repeat Markup. . .    I haven't seen the use for it.   I've been trying to climb the mountain to get the message. . .    but sorry, I'll just keep going to a different church.<br><br><br><br><br><br><br>
  • greim 2006-02-21 11:35
    Goog god! XML is painful enough if you do it the *right* way.
  • PKman 2006-02-21 11:46
    masklinn:
    Alex Papadimoulis:
    it is, after all based on HTML

    <p>no</p>
    Alex Papadimoulis:
    look at HTML

    <p>Fully defined and specified special-purpose (DSL) markup language, SGML application</p>
    Alex Papadimoulis:
    Then look at XML.

    <p>A metalanguage or a general purpose markup language used to create special-purpose language</p>
    Alex Papadimoulis:
    Then look at SGML.
    <br><br><br><br>
    <p>A metalanguage or a general purpose markup language used to create special-purpose language</p>
    Alex Papadimoulis:
    It's pretty clear who's a child of whom.

    <p>XML is not a child, it's a giant step.</p>
    <br><br><br>Yeah, a giant step off the edge of the f*ckin world<br>
  • maldrich 2006-02-21 12:00
    I think the way to do this "properly" is to write a SQL stored procedure that uses sp_OACreate to make an OLE Automation object write and read flat files directly from the filesystem. That would greatly improve the extensibility of the system by removing all the "obstacles" presented by the RDBMS, such as columns, tables, views and indexes. Pure freedom to store the data as any format required by the end user. Heck, you could just give them the tools to write their own binary files. Ultimate freedom, ultimate extensibility. They could just type 000001101001001001111100110. Or use XML if they want. And you would not need to use that old fashioned SQL language much at all. Just pass in all the parameters to the stored proc, and off you go.<br><br>Plus it'd be really fast, by avoiding all the overhead caused by the database objects.<br><br>(Kidding. Sign me up to fix it afterward, though. Seems like there could be a lot of money in that, if you could avoid killing yourself halfway through.)<br>
  • Fregas 2006-02-21 12:01
    <P>
    Satanicpuppy:
    <BR><BR>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.<BR>
    </P>
    <P>Uh, I would argue that what you are talking about (a table for every year/month/etc) is WTF in itself.&nbsp; There have been various posts on here with people doing that very thing.&nbsp; If you have too much data, archive it over to a read-only&nbsp;reporting server.&nbsp; But please don't make a bunch of duplicate tables.&nbsp; Repeating data structures is almost as bad as repeating data!&nbsp; They did exactly what you are discussing over at True.com and it was a huge WTF when they wanted some kind of report over several months or years.&nbsp; UNION this month table, with next months table, with the next months tables...etc.&nbsp; Unions galore.&nbsp; ug!</P>
    <P>DRY: Don't Repeat Yourelf.&nbsp; </P>
  • Otto 2006-02-21 12:17
    Anonymous:
    <br>You're a fag.<br>...<br>Fucking poser.<br><br>Ass-monkey.<br>
    <br><br>Sir, your masterful use of the "WTF" debating style leaves me astounded.&nbsp; Truly, you are gifted in the art of WTFery.<br><br>
  • A Nonny mouse 2006-02-21 12:53
    Anonymous:
    johnl:

    <P><SPAN><SPAN style="FONT-STYLE: italic">As a patron member of said cult, I should note that this is the *only* thing that gives XML its power. </SPAN><BR></SPAN></P>
    <P><SPAN>Indeed, I agree with that.&nbsp; But you can't argue that that power exists, it exists for a reason, and that at the moment there's nothing else that has that property.&nbsp; Ok, maybe CSV, but that can't handle anything more complex than a single table.<BR></SPAN></P>
    <P style="FONT-STYLE: italic"><SPAN>I should also note that "works" is a pretty low standard - I could base a data-exchange language on Microsoft Word, and that would still work.</SPAN></P>
    <P>Not without giving up a lot of functionality - just being plain text has a lot going for it, you know.&nbsp; I agree, it is a fairly low standard, and no-one's claiming that XML's perfect, or that if it was all done again, it might be done differently.</P>
    <P><SPAN>
    <BLOCKQUOTE></BLOCKQUOTE></SPAN>
    <P></P>
    <P style="FONT-STYLE: italic"><SPAN>There have been better alternatives to XML long before XML came around. Let us remember that XML post-dates HTML; it is, after all based on HTML (get the comment on MS Word above, they're both display documents?). <BR></SPAN></P>
    <P><SPAN>Not quite...&nbsp; XML shares syntactical style with HTML, but that does not mean it's a direct descendant, more of a younger sibling.&nbsp; <BR></SPAN></P>
    <P>Name some superior alternatives to XML that were around before XML came on the scene, and we can tell you why we're using XML rather than those alternatives.&nbsp; Even if that's just because no-one knew about the alternative (see my comment on JSON)<BR>
    <BR><BR>Sheesh. . .<BR><BR>CSV was a good idea before PKZip came along.<BR><BR>XML could not survive without something like PKZip.<BR><BR>XML has served to create a need for humungous disk drives. . .&nbsp;&nbsp; lots of memory for parsers to "work".&nbsp;&nbsp;&nbsp; For providing a standardizable way of presenting data for printing i.e., Markup&nbsp; repeat Markup. . .&nbsp;&nbsp;&nbsp; I haven't seen the use for it.&nbsp;&nbsp; I've been trying to climb the mountain to get the message. . .&nbsp;&nbsp;&nbsp; but sorry, I'll just keep going to a different church.<BR><BR>
    </P>
    <P>We use&nbsp;xml, as johnl outlined in an earlier post, for transmission between systems (and organisations). It's largely temporary and needs neither big disk drives or lots of memory. My company would be way too cheap to pay for either. Even where we have saved records off neither of these has been an issue. We don't use PKZip for anything XML related.</P>
    <P>Like anything else, it can be used and abused.</P>
  • Integration Nation 2006-02-21 13:13
    <P>This XML panacea is so similar to the proliferation of integration software I see permeating the industry.&nbsp; First, everyone rode the CRM wave, then the HIPAA/SarbanesOxley wave, now we're back on the (almost dead--now has new life) integration server wave thanks to all these funky XML formats flying around.</P>
    <P>Man.&nbsp; I fucking hate it when people&nbsp;dump on BizTalk (2004, earlier versions were all crap).&nbsp; People dump on it for a reason that they don't understand:&nbsp; VERY FEW organizations should be using BizTalk.&nbsp; And I mean FEW.&nbsp; Most BizTalk implementations fail or overcomplicate environments because it's being used as a golden hammer.</P>
    <P>If you are already using EDI format for partner transactions, maybe you could use BizTalk... (perhaps... sort-of).</P>
    <P>If you are migrating from one database to another and you don't have the luxury of cutting everyone over all at once to a new design, BizTalk is a wonderful tool to use in a large scale migration project where you have both environments operating in your org simultaneously.</P>
    <P>If you&nbsp;are seeking to integrate more than 4-5 stovepipe apps that CANNOT and WILLNOT be removed from the environment, then BizTalk will definately help you merge them closer.</P>
    <P>If you deal with processes that begin outside your org and end outside your org, then BizTalk is the ideal solution there.</P>
    <P>Too many people shove BizTalk into an environment where it just doesn't belong simply because they believe that their heavy use of XML passing warrants it.&nbsp; I have seen BizTalk used at a client site within a SINGLE application before.&nbsp; The app was not talking to any partners, it only had one DB2 database, and the client was WebForms C#.&nbsp; But the whole friggin' business logic was stuffed into BizTalk which made it a nightmare to make changes to the app.&nbsp; Plus, data was duplicated between DB2 and BizTalk since the wonderful "consultant" at a rather wealthy and well-to-do firm chose not to directly operate on DB2 from BizTalk (hint... the shop's first name starts with C and their last name begins with a vowel).</P>
    <P>I'm not just nagging BizTalk. This argument applies to all integration vendors like TIBCO or K2 (but I wouldn't use K2 since it's non-performant crap... just because it's written in C# doesn't make it worth using).</P>
    <P>I'm sure after a year or so this client is going to have to bring in an army from Hyderabad or Bangalore to fix this.&nbsp;&nbsp; What a mess.</P>
    <P>I almost hate XML and B2B work because of this stupidity and the consultants running around rampant promoting this overcomplexity.&nbsp; Alas, I make $67/hr consulting these fools into fixing their own messes...</P>
  • Richard 2006-02-21 13:31
    Okay, so this is clearly a WTF, but I don't see why people are constantly beating up on XML use in databases.<br><br>We run something quite similar for a number of our systems <span style="font-weight: bold;">EXCEPT </span>before I get jumped up and down on it's as a blob add on to the existing normalised databases, XML is never searched on and is not used for relationships etc.<br><br>The reason for doing it is that we have a large number of small projects where the end result is similar with clients wanting an occassional extra field here or there, just for minor customisation.  We've an x-form that controls both render, validation and data collection for our stored procedures so instead of having to make any database schema changes when client X wants to add some such display field that isn't bound to anything else in the schema, or searched upon or would need to be normalised we can just copy a couple of lines in the x-form and everything works just as before.<br>
  • masklinn 2006-02-21 14:24
    Anonymous:
    Yeah, a giant step off the edge of the f*ckin world<br>

    <p>You're lacking a few XML-related references, I was quoting Erik Naggum who once stated that:</p>
    <blockquote><p>XML is a giant step in no direction at all.</p></blockquote>
    <p>;-)</p>
  • Adam 2006-02-21 16:18
    This reminds me of that Seinfeld episode where Kramer gets a vasectomy.  Whose brainchild was this?<br>
  • John Hensley 2006-02-21 19:02
    XML is an interchange format, people!   IN-TER-CHANGE!!!!!<br>
    <br>
    The real WTF will come when this company decides to make XML dumps of
    its database that contains XML text, at which point the developer
    responsible may or may not remember to escape the angle brackets. It'll
    look rather WTF either way.<br>
    <br>
  • felix 2006-02-21 23:57
    johnl:
    <span id="_ctl0_PostForm_Reply"><br>Someone
    mentioned JSON.&nbsp; I've never heard of JSON before now, and I doubt
    many other people have either.&nbsp; So why should I spend a lot of
    time implementing JSON into my application as, say an export format,
    when no-one can import it?<br></span>
    <br>
    <br>
    Because you can just visit http://www.json.org/ and grab the library
    for one of the 22 officially languages supported? By the way, you
    mentioned AJAX. JSON is a strict subset of Javascript. Need I say more?<br>
    <br>
  • felix 2006-02-22 00:03
    johnl:
    Name some superior alternatives to XML that were
    around before XML came on the scene, and we can tell you why we're
    using XML rather than those alternatives.&nbsp; Even if that's just
    because no-one knew about the alternative (see my comment on JSON)<br>
    <br>
    <br>
    Lua. Yes, it's a full-fledged programming language, but data
    description is one of its main uses. You didn't know about it? Your
    loss.<br>
    <br>
  • suresk 2006-02-22 01:40
    sammybaby:
    <p>I swear to god, I made a joke about doing just this very thing <a href="http://slashdot.org/comments.pl?sid=177985&cid=14762697">on Slashdot today</a>.</p>
    <p>My joke was arguably worse, though, as the "data" took the form of serialized objects instead of xml fragments.</p>
    <br><br>Ummm... Did we work for the same company? The very first "real" job I had, I ran into that exact same issue. It saved the original programmer about an hour of programming, but any mass edit to the database took forever. Grab row -> Unserialize -> Check Conditions -> Update Object -> Reserialize -> Update. WTF???<br><br>I've also run into string parsing in mySQL, and then joining on the results. PITA to use or debug. Operating a DB should require a license.<br>
  • johnl 2006-02-22 06:03
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">CSV was a good idea before PKZip came along.</span><br><br>Er... I'm not sure if we're talking at cross-purposes here, but isn't PKZip a compression utility, and one that you have to pay for, judging by www.pkware.com.&nbsp; If I want to transmit data in plain text, why do I need a binary compression format?<br><br><span style="font-style: italic;">XML
    has served to create a need for humungous disk drives. . .&nbsp;&nbsp;
    lots of memory for parsers to "work".&nbsp;&nbsp;&nbsp; For providing a
    standardizable way of presenting data for printing i.e., Markup&nbsp;
    repeat Markup. . .&nbsp;&nbsp;&nbsp; I haven't seen the use for
    it.&nbsp;&nbsp; I've been trying to climb the mountain to get the
    message. . .&nbsp;&nbsp;&nbsp; but sorry, I'll just keep going to a
    different church.</span><br style="font-style: italic;"><br>Fair enough.&nbsp; I'm not a pro-XML fanatic, by the way, but the fact that I'm not an anti-XML fanatic seems to make you think I am.&nbsp; I've already described some very good uses for it, and there are some more that I didn't mention.&nbsp; For example, Installshield now allows you to store your installation project as an XML file.&nbsp; This is pig-slow, but it has benefits - you can do text comparisons to see what's changed (great for source control), source control systems store the file as deltas, and you are able to use XML-compatible languages to edit the project programmatically (for example, I use this to set the installation version number and file paths in my NAnt builds).<br></span>
  • Bellinghman 2006-02-22 06:33
    Why use PKZip? Well, you wouldn't, per se. You'd use a compression library. Personally, zlib works well for us - we have both C++ and Java implementations of that.

    Why use compression? Because that XML data is so bloated, and running it through compression will reduce its size by a factor of at least 10, quite possibly 100 on large chunks.

    Why reduce it? I don't know about you, but we have customers who have some relatively slow network links (e.g. out to Guam), and they really don't appreciate having those links saturated with XML bloat. It's also actively quicker to take the XML, compress it, UUEncode it to be safe from non-8-bit-clean links, transmit it and reconstitute it at the far end than to send it uncompressed.

    It also takes less space inside a database (and the XML is not intended to be indexed).

    You also seem to be confused about compression in general. A good binary compressor does so by spotting patterns in its input - the more patterns, and the longer, the better. Being text is a major pattern, which is why PKZip is so good at compressing textual data.
  • johnl 2006-02-22 07:45
    @felix:&nbsp; Clearly you do need to say more, because I don't get what you're driving at.&nbsp; I'm not going to visit the site if I don't know about it, am I?&nbsp; And AJAX uses XML, so the fact that JSON is a subset of Javascript doesn't make any difference because AJAX already has a data representation system.&nbsp; MAybe you're saying that JSON would have been a better alternative to AJAX, in which case you might be right.&nbsp; But as I pointed out earlier, acceptance is an important part of why XML is popular - everyone uses it because the people who they'll exchange data with are using it.<br><br>@Bellingham:<br><span id="_ctl0_PostForm_Reply"><br><span style="font-style: italic;">Why use compression? Because that
    XML data is so bloated, and running it through compression will reduce
    its size by a factor of at least 10, quite possibly 100 on large
    chunks.
    </span></span><br><br>Ok, you've just killed the data interchange thing for a lot of people because you're now using a binary format, which is not guaranteed to be compatible across all systems.&nbsp; ASCII and Unicode are compatible across almost all computer systems, though Unicode may have a lower rate of success in this regard.<br><br>It also hurts most source control systems because they don't store binaries as delta, so compressing your data isn't a good idea there either (it's usually better to leave it uncompressed so the system can store it as a delta, which, believe it or not, is smaller than a full revision).&nbsp; <br><br>And you've also just decided that, once you've exported your data, no-one should be able to do anything with it other than export it into the destination system.<br><br>So, for example, you want to transfer data between two systems with a different schema.&nbsp; You can export your data as XML, run a transform on it to convert it to the schema the destination system uses, then import it into the destination system.<br><span id="_ctl0_PostForm_Reply"><br><span style="font-style: italic;">You also seem to be confused about
    compression in general. A good binary compressor does so by spotting
    patterns in its input - the more patterns, and the longer, the better.
    Being text is a major pattern, which is why PKZip is so good at
    compressing textual data.</span><br><br>I never said anything that disagrees with this.&nbsp; The fact is that the compression results in a binary stream.&nbsp; Key word:&nbsp; Binary.&nbsp; Not text.&nbsp; Binary.&nbsp; Sometimes people need to work on their files as text.<br><br>The only thing I can think of that would make your argument make sense is if you were saying that you should compress the data during the transmission, then uncompress on the other side.&nbsp; That's fine, as long as the destination has access to the same compression algorithm, and yes it probably would help if you're transferring over a slow network.<br></span>
  • johnl 2006-02-22 07:48
    Oh, and you've also said that no-one should be able to compare the data with standard comparison utilities like WinMerge.<br>
  • masklinn 2006-02-22 08:18
    johnl:
    @felix:&nbsp; Clearly you do need to say more, because I don't get what you're driving at.&nbsp; I'm not going to visit the site if I don't know about it, am I?&nbsp; And AJAX uses XML, so the fact that JSON is a subset of Javascript doesn't make any difference because AJAX already has a data representation system.&nbsp; MAybe you're saying that JSON would have been a better alternative to AJAX, in which case you might be right.&nbsp; But as I pointed out earlier, acceptance is an important part of why XML is popular - everyone uses it because the people who they'll exchange data with are using it.

    <p>Ajax doesn't "use" shit, ajax is already an abused and borderline retarded buzzword, please don't start spawning even more retarded buzzword just cause you don't want people to use JSON in AJAX.</p>
    <p>Fact is you're too late anyway, people are using ajaxy methodologies using JSON, raw HTML or even raw text as a data transport layer already.</p>
    <p>Oh, and JSON is not "an alternative to AJAX" btw, it's an alternative to XML as a data transport layer in scripted asynchroneous communications.</p>
    <p>Oh, BTW, most Yahoo ajaxy services use JSON already, not xml...</p>
    <p>Now if you can be bothered with at least somewhat thought of opinions on the subject <a href="http://www.quirksmode.org">PPK from QuirksMode</a> posted to interresting pieces with even more interresting comments as <a href="http://www.quirksmode.org/?http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html">The AJAX response: XML, HTML or JSON</a> and <a href="http://www.quirksmode.org/?http://www.quirksmode.org/blog/archives/2006/01/the_ajax_respon_1.html">The AJAX Response - Part 2</a></p>
  • Sooper Doody 2006-02-22 08:29
    <P>Unfortunately jamming XML everywhere in the database is a trend where I work.&nbsp; Its a total nightmare to deal with this data.&nbsp; Please someone send me the toe attachment for my shot gun.&nbsp; People who think XML should be "jammed" everywhere should be shot. </P>
    <P>- Sooper Doody! </P>
  • johnl 2006-02-22 08:31
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Ajax doesn't "use" shit, ajax is
    already an abused and borderline retarded buzzword, please don't start
    spawning even more retarded buzzword just cause you don't want people
    to use JSON in AJAX.</span><br style="font-style: italic;"><br>Do you have trouble reading or something.&nbsp; I don't know anything about JSON.&nbsp; That's the friggin' point.&nbsp; If people don't know about an interchange format, then it's friggin' useless as an interchange format.&nbsp; I haven't decided that I don't like JSON, just that it's only an alternative to XML (at least, what XML was intended to be) if people know about it.&nbsp; So far, not many people know about it.<br><br></span><span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Oh, and JSON is not "an alternative to
    AJAX" btw, it's an alternative to XML as a data transport layer in
    scripted asynchroneous communications.</span><br style="font-style: italic;"><br>Explain that to felix, since he seems to think JSON is an alternative to AJAX.&nbsp; Anyways, see above.<br></span><br><span style="font-style: italic;">Now if you can be bothered with at least somewhat thought of opinions on the subject </span><a style="font-style: italic;" href="http://www.quirksmode.org/">PPK from QuirksMode</a><span style="font-style: italic;"> posted to interresting pieces with even more interresting comments as </span><a style="font-style: italic;" href="http://www.quirksmode.org/?http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html">The AJAX response: XML, HTML or JSON</a><span style="font-style: italic;"> and </span><a style="font-style: italic;" href="http://www.quirksmode.org/?http://www.quirksmode.org/blog/archives/2006/01/the_ajax_respon_1.html">The AJAX Response - Part 2</a><br style="font-style: italic;"><br>It's off-topic anyway, I'll look at it if and when I decide that I'd need to do something like this.<br>
  • Nyne 2006-02-22 09:15
    all I can say is... wow<br>
  • jamisonkfox 2006-02-22 09:22
    I had a client once who demanded a database be scalable, capable of handling any number of user field additions, and run smoothly for their nationwide user base on a machine with a tiny processor and less than a gig of ram.&nbsp;&nbsp; I left, maybe this guy came in :)<br>
  • Richard Nixon 2006-02-22 09:48
    masklinn:
    johnl:
    @felix:&nbsp; Clearly you do need to say more, because I don't get what you're driving at.&nbsp; I'm not going to visit the site if I don't know about it, am I?&nbsp; And AJAX uses XML, so the fact that JSON is a subset of Javascript doesn't make any difference because AJAX already has a data representation system.&nbsp; MAybe you're saying that JSON would have been a better alternative to AJAX, in which case you might be right.&nbsp; But as I pointed out earlier, acceptance is an important part of why XML is popular - everyone uses it because the people who they'll exchange data with are using it.

    <p>Ajax doesn't "use" shit, ajax is already an abused and borderline retarded buzzword, please don't start spawning even more retarded buzzword just cause you don't want people to use JSON in AJAX.</p>
    <p>Fact is you're too late anyway, people are using ajaxy methodologies using JSON, raw HTML or even raw text as a data transport layer already.</p>
    <p>Oh, and JSON is not "an alternative to AJAX" btw, it's an alternative to XML as a data transport layer in scripted asynchroneous communications.</p>
    <p>Oh, BTW, most Yahoo ajaxy services use JSON already, not xml...</p>
    <p>Now if you can be bothered with at least somewhat thought of opinions on the subject <a href="http://www.quirksmode.org">PPK from QuirksMode</a> posted to interresting pieces with even more interresting comments as <a href="http://www.quirksmode.org/?http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html">The AJAX response: XML, HTML or JSON</a> and <a href="http://www.quirksmode.org/?http://www.quirksmode.org/blog/archives/2006/01/the_ajax_respon_1.html">The AJAX Response - Part 2</a></p>
    <br><br>Bad day at the office pal?<br><br>sincerely,<br>Richard Nixon<br>
  • johnl 2006-02-22 10:21
    <span id="_ctl0_PostForm_Reply">Sorry, missed this bit:<br><br><span style="font-style: italic;">Oh, BTW, most Yahoo ajaxy services use JSON already, not xml...</span><br><br>Then it's not really AJAX, is it?&nbsp; Asynchronous Javascript And XML.&nbsp; Note XML.&nbsp; Essentially, they've used Javascript (including JSON) to reproduce what AJAX does.&nbsp; Actually, thinking about it, GMail also uses Javascript to transfer data, so it might be JSON too.&nbsp; Still doesn't in any way invalidate what I said, though<br></span>
  • Bellinghman 2006-02-22 10:41
    "The only thing I can think of that would make your argument make sense is if you were saying that you should compress the data during the transmission, then uncompress on the other side. That's fine, as long as the destination has access to the same compression algorithm, and yes it probably would help if you're transferring over a slow network."

    By George, I think you're got it!

    Yes, of course you need the same algorithm at compression and decompression points. Why do you think I mentioned that we went for zlib? As I said, we've got it in both C and Java implementations.

    For cases where you're moving XML data between endpoints under your own control, then compression /decompression can be an enormous optimisation. That includes going over non-local network links and storage for later use.

    This is why XML bloat isn't as much of a problem as it could be.

    Note - some network links, databases and file systems may do automatic compression. In such cases, you will not want to bother doing a second level of compression. But I'll assume that you're experienced enough to know the usual caveats about optimisation.
  • johnl 2006-02-22 11:12
    Yeah, I can see that's why you went for ZDlib.&nbsp; Though is that algorithm available to other languages?&nbsp; I seem to remember it being available for C#/.NET, but what about, say, Ruby, Python, and so on?&nbsp; (Just asking since I'm not sure)&nbsp; Even if it is available for other languages, you can still get into situations where they can't/won't use it because they'd have to uncompress the data.&nbsp; You can do that on the command line, but if this is meant to be an automated system, then they'd have to find a way of getting that system to call the uncompression command.&nbsp; If they recieve data from other sources, some compressed, some not, some compressed with different algorithms...&nbsp; That could be painful.&nbsp; And if the system is off-the-shelf, then they could well be screwed.<br><br>Besides, you still have to create that textual data.&nbsp; It could be a JSON packet or an XML document or whatever - you want to zip it.&nbsp; But that's not what's under discussion here, hence my original confusion.<br>
  • Otto 2006-02-22 11:21
    For the particular case of AJAX, where you're sending XML to a browser, you can generally reduce bandwidth dramatically by simply using mod_gzip (or gzipping the XML in your program if that makes more sense... just make sure to check the Accept-Encoding: header to see if the browser can take gzipped data).<br>
  • hank miller 2006-02-22 11:38
    johnl:
    Yeah, I can see that's why you went for ZDlib.  Though is that algorithm available to other languages?  I seem to remember it being available for C#/.NET, but what about, say, Ruby, Python, and so on?  (Just asking since I'm not sure)  Even if it is available for other languages, you can still get into situations where they can't/won't use it because they'd have to uncompress the data.  You can do that on the command line, but if this is meant to be an automated system, then they'd have to find a way of getting that system to call the uncompression command.  If they recieve data from other sources, some compressed, some not, some compressed with different algorithms...  That could be painful.  And if the system is off-the-shelf, then they could well be screwed.


    What cave have you been living in for the last 15 years? There are no major (large) computers that do not have some form of zip available. Even when not installed by default, odds are the user installed it himself because it is so common.

    Okay, the computer in your microwave is unlikely to have zip (though I wouldn't be surprised if it was there for some development purpose and never removed), but they don't do network communication. Likewise you might find a PDP-8 still in use somewhere without zlib. Nothing reasonably current

    Python has Zlib. Ruby has it. Included in the default install (of current versions) because it is so common and useful. If you used google on your favorite language and zlib, I'm sure you would find it.

    We are not talking about something new or controversial, we are talking about zlib. Easy to use by any competent programmer - from their program. If your protocol is well designed at all, it will be easy to tell the other end to uncompress the data first.
  • Otto 2006-02-22 11:48
    felix:

    <br>
    Because you can just visit http://www.json.org/ and grab the library
    for one of the 22 officially languages supported? By the way, you
    mentioned AJAX. JSON is a strict subset of Javascript. Need I say more?<br>
    <br>I think the real problem here is that thus far, nobody has really been able to satisfactorily justify a dislike of XML in favor of JSON. So let's run the issues, eh?<br><br>Size: XML could be said to be larger due to a larger set of descriptors and such. However I think that in practice this would rarely be the case. The point of XML is to provide a description of data, and JSON contains, essentially, those same descriptive elements. The only real difference in size terms is that JSON uses slightly smaller sets of symbols (like brackets and parenths instead of &lt;xxx&gt; and &lt;/xxx&gt; and such). However, the difference in any reasonable set of data is going to be small, and with compression such as gzip encoding to browsers, the difference in size is going to be virtually non-existent.<br><br>Ease of use: JSON is significantly easier to use in javascript, as all you have to do is to eval the thing and you get a javascript object back, which you can then reference directly. This is a massively huge security hole, however, so you need to use a bit more javascript with some regular expressions to *correctly* parse the thing. For non JS languages, you can get libraries and such to do that parsing for you. However, XML is much the same in this respect, since all modern browsers have fairly easy-to-use XML parsers built right in, so really it's not all that complicated, using getNodeValue's and such. All modern languages have XML libraries available too, so there's also not a lot of benefit there either.<br><br>Readability: Both JSON and XML are more or less human readable, although it can be argued that JSON "looks cleaner" because of lack of all those greater and less than brackets around everything. It also more directly represents the underlying data structure. This is really a matter of taste more than anything else, and considering that modern browsers render XML into a hierarchical display with expand/collapse links by default, XML really wins on this score. Not to mention that you can use an XSL transformation to render the XML in a pretty format for those cases where you're actually loading it into a browser, while leaving it unchanged for those cases where you're not loading it into a browser.<br><br>Speed: It could be argued that JSON is faster to parse in javascript, which is to an extent true. The format itself fits the language guidelines directly, so it's a simple matter of an eval. However, what with the XML parsers built into browsers being usually compiled into native code, and what with the regular expressions needed to make eval'ing a JSON file safe, I'd say that the difference is not as wide as you'd think. I'd want to see actual profiling before making a determination there, and would not consider this to be universally true.<br><br>In the end, it's a matter of preference. While it's true that Yahoo now offers most of their webservices using JSON, this is relatively new ( &gt;3 months old, I think), and it's offered as an alternative to their more traditional XML webservices. Basically you can get the same data either way. They have switched to using JSON on some (not all) of their own apps for speed reasons, and that makes sense for those apps. But that's not going to hold true for all applications.<br><br>
  • Integration Nation 2006-02-22 12:07
    <P>People who put XML databases are usually the same people who have <STRONG>NEVER, EVER</STRONG> had to work with OLAP tools or reporting engines.</P>
    <P>When you can click-click-click inside Crystal and extract, aggregate and summarize XML-embedded data within a database AND it is also rationable and easy to use by any novice-level analyst will be the day my penis turns blue and falls off.</P>
  • johnl 2006-02-22 12:10
    But not just any old thing will do.&nbsp; Ok, so zip is pretty damn common, but that doesn't mean your destination system can use it.<br><br><span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Python has Zlib. Ruby has it. Included in the default install (of
    current versions) because it is so common and useful. If you used
    google on your favorite language and zlib, I'm sure you would find it.
    </span><br style="font-style: italic;"><br>I thought it might.&nbsp; I just wasn't sure.<br><br></span><span id="_ctl0_PostForm_Reply"></span><span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">We are not talking about something
    new or controversial, we are talking about zlib. Easy to use by any
    competent programmer - from their program. If your protocol is well
    designed at all, it will be easy to tell the other end to uncompress
    the data first.</span><br style="font-style: italic;"><br>Ok, smart-arse, I'm running your destination system.&nbsp; You send me data compressed with zdlib.&nbsp; Can you think of the possible scenarios?&nbsp; Tell you what, I'll list a few for you, save you the trouble:<br><br>1. I say "it's a closed source 3rd party system, and it doesn't accept compressed data".<br>2. I don't have time to adapt my system, even if it is a trivial change.&nbsp; Likewise, I don't have time to take a critical system offline to update it just because your network is slow.<br>3. Some of the people sending us data don't compress it (they have super-fast magical networks that don't die horribly at the first sight of a few lines of text, the lucky devils).&nbsp; We now need to keep track of who compresses their data and who doesn't.&nbsp; Which we don't have the time for.<br>4. Someone else gets in on the act, only they don't like ZIP format, they want to use LHA (or some other compression algorithm) instead.&nbsp; Maybe we could support multiple formats, but that just compounds points 2 and 3.<br>5. My system isn't transferring over a slow network - maybe it's purely local (say, from one database to another, or one application dumping some XML for another to pick up).&nbsp; So why do I need this extra step to compress/decompress data?<br>6. Maybe I'm not transferring the data anywhere - maybe I'm converting it to XML to work with in the same system simply because that's easier to work with in my situation than leaving it a binary format.&nbsp; So, again, why is the compression/decompression step needed?<br><br>I can't understand what the problem with this concept is.&nbsp; I'm not even arguing against the idea that zlib is useful in this context - I'm sure it is.&nbsp; I'm telling you (something that you should already know) that it isn't always necessary or feasible to implement that.&nbsp; I'm also trying to point out that, whether you zip it or not, XML is still a viable choice for working with data as text.&nbsp; It may not be the fastest, or the most readable (though I don't have any issues with it), or the smallest, but it's there, it works and it's well-supported by many applications.<br></span>
  • johnl 2006-02-22 12:32
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">People who put XML databases are usually the same people who have </span><strong style="font-style: italic;">NEVER, EVER</strong><span style="font-style: italic;"> had to work with OLAP tools or reporting engines.</span><br><br>Or maybe they just don't have to on that project, or even that part of the project.&nbsp; Truth be told, the system we're working on (close to release) uses both Crystal reports and SQL Notification Services.&nbsp; The server-side application will dump a piece of XML in the notifications database to be picked up by the client application.&nbsp; No OLAP tool or reporting engine ever goes near it.&nbsp; The message only exists in the database until the client picks it up.&nbsp; It's not something you'd want to report on.<br><br>The advantage of using XML in this case is that we can use whatever schema we want.&nbsp; Some of these messages have images embedded in them (specifically, a fragment of a map around a specific point), some don't.&nbsp; Since Notification Services is an off-the-shelf system, it would be impossible for the developers of it to know what schema should be used (should it have a binary field for an image or not?), so a dynamic schema is the way to go, and XML is a viable way to do that in this case.<br><br>However, think carefully before embedding XML in databases - it's usually not a good thing to do.<br></span>
  • masklinn 2006-02-22 12:34
    johnl:
    Then it's not really AJAX, is it?&nbsp; Asynchronous Javascript And XML.&nbsp; Note XML.&nbsp; Essentially, they've used Javascript (including JSON) to reproduce what AJAX does.

    <p>God... I don't even want to bother with that so I'll just quote PPK and be done with it:</p>
    <blockquote><p>On the XML side of the debate I noticed one fallacy: the fact that the name AJAX has "XML" in it. Although some say this means that XML is the "best" output format, I fully side with their opponents. The name AJAX has been badly chosen, and although it's far too late to turn back the clock and pick a better name, please <em>remember that the phrase was coined by a non-technical person who wanted to point out a useful trend in JavaScript, and not by someone who wanted to lay solid technical foundations for this trend</em>.</p>
    <p>Therefore, the fact that "AJAX" has an X for XML doesn't mean anything. In fact, this whole discussion is meant to see if the X is useful or not.</p></blockquote>
    <p>(emphasis mine)</p>
  • johnl 2006-02-22 12:39
    Well, that explains that one then.&nbsp; Care to look at any of the otehr points, or is it all just too much trouble for you?<br>
  • masklinn 2006-02-22 13:58
    johnl:
    Well, that explains that one then.&nbsp; Care to look at any of the otehr points, or is it all just too much trouble for you?<br>

    <p>Since I don't know what "the other points" are i'll just go through every post of yours since my previous one.</p>
    johnl:
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Ajax doesn't "use" shit, ajax is
    already an abused and borderline retarded buzzword, please don't start
    spawning even more retarded buzzword just cause you don't want people
    to use JSON in AJAX.</span><br style="font-style: italic;"><br>Do you have trouble reading or something.&nbsp; I don't know anything about JSON.&nbsp; That's the friggin' point.&nbsp; If people don't know about an interchange format, then it's friggin' useless as an interchange format.&nbsp; I haven't decided that I don't like JSON, just that it's only an alternative to XML (at least, what XML was intended to be) if people know about it.&nbsp; So far, not many people know about it.

    <p>JSON is a lightweight data serialisation and interchange format. It's name is the acronym of JavaScript Object Notation, because it's merely the literal notation of object definition in Javascript. It should also be noted that JSON is at the same time a notation for dictionaries/maps in some other languages (e.g. Python). It can also use Javascript's Array literal notation for series of data. Here is an example of JSON data:</p>
    <blockquote><pre>{"user": {
    "surname":"Mask",
    "name":"Leen",
    "location":"TDWTF",
    "characteristics": [
    "Information Technology Pervert",
    "Troll"
    ]
    }
    }</pre></blockquote>
    <p>One of the great advantages of JSON (on top of being extremely easy to generate) is the fact that Javascript's <code>eval</code> is theorically all that's required to parse it, making it extremely efficient in parsing time and in using the data itself (since it's used in a regular JS-object access way, and not through a "third-party" interface). In practice, using <code>eval</code> on raw JSON is unsafe, and using the parsing function provided by JSON.org is much safer (it merely uses REs to scan the syntax of the JSON string and returns false if an error is detected. The package also provides functions to serialize Javascript objects in order to send them to the server).</p>
    <p>It should also be noted that JSON is a subset of the more complex <a href="http://yaml.org/">YAML</a> (and since YAML is the <em>de facto</em> data serialization format of Ruby, Ruby has no trouble parsing JSON data even though the JS object literal doesn't map any Ruby structure).</p>

    johnl:
    <span style="font-style: italic;">Oh, and JSON is not "an alternative to
    AJAX" btw, it's an alternative to XML as a data transport layer in
    scripted asynchroneous communications.</span><br style="font-style: italic;"><br>Explain that to felix, since he seems to think JSON is an alternative to AJAX.

    <p>I couldn't conclude that from what I saw, what I read in Felix' posts was that AJAX heavily uses Javascript, and that JSON is native Javascript, therefore a logical data interchange format.</p>


    That's the only post of yours I found things I could/should answer to, anything else needed?</p>
    Otto:
    Ease of use: JSON is significantly easier to use in javascript, as all you have to do is to eval the thing and you get a javascript object back, which you can then reference directly. This is a massively huge security hole, however, so you need to use a bit more javascript with some regular expressions to *correctly* parse the thing.

    <p>Yes, that regular expression to validate the string is available at JSON.org (the final parsing function takes something like 3 lines, they provide a much more complex Javascript > JSON serializer though)</p>
    Otto:
    However, XML is much the same in this respect, since all modern browsers have fairly easy-to-use XML parsers built right in, so really it's not all that complicated, using getNodeValue's and such.

    <p>Using raw JS object notation still is much easier (and usually more readable) than using the DOM interface to extract data from the XML document. Or so I think.</p>

    <p>Nothing to add on your other points.</p>
  • felix 2006-02-22 14:05
    johnl:
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;"></span><br style="font-style: italic;">Do
    you have trouble reading or something.&nbsp; I don't know anything
    about JSON.&nbsp; That's the friggin' point.&nbsp; If people don't know
    about an interchange format, then it's friggin' useless as an
    interchange format. <br>
    <br>
    <br>
    Erm... if you don't know about it, shouldn't you go take a look?<br>
    <br>
    </span>
    johnl:
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;"></span><br style="font-style: italic;"></span><span id="_ctl0_PostForm_Reply">Explain that to felix, since he seems to think JSON is an alternative to AJAX.&nbsp; Anyways, see above.<br></span><span id="_ctl0_PostForm_Reply">
    <br><br>
    Read my post again, will you? And rememeber that&nbsp; XmlHttpRequest
    can handle data in any format. Even binary. AJAX itself is just a
    buzzword. It doesn't have to use XML. And if you have Javascript on the
    receiving end, JSON makes a better format, 'cause it <span style="font-weight: bold;">is</span> JS. You can deserialize a chunk with a simple call to eval(). There. Did I really need to explain that?<br>
    </span><br>
  • johnl 2006-02-22 15:24
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Since I don't know what "the other points" are i'll just go through every post of yours since my previous one.</span><br><br>I meant "read my post" so I guess that works<br><br></span><span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">JSON is a lightweight data serialisation and interchange format. It's... &lt;snip&gt;</span><br><br>My point was that JSON isn't as well-known as XML.&nbsp; Telling me about JSON doesn't change that - though I do appreciate the information, I could find out for myself now that it's been mentioned, if I was really interested in the specifics of the implementation.<br><br>But since I'm looking into Ruby at the moment, the Ruby link is interesting.</span><br><br><span style="font-style: italic;">I couldn't conclude that from what I saw, what I read in Felix's
    posts was that AJAX heavily uses Javascript, and that JSON is native
    Javascript, therefore a logical data interchange format.</span><br style="font-style: italic;"><br>I read it as "don't use AJAX - use JSON instead!"&nbsp; Maybe I misread it though.<br><br><span style="font-style: italic;">


    That's the only post of yours I found things I could/should answer to, anything else needed?</span><br><br>Well, I think that's all the ones in direct response to you...<br>
  • johnl 2006-02-22 15:30
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Erm... if you don't know about it, shouldn't you go take a look?</span><br><br>You really don't get it, do you?&nbsp; Who cares whether <span style="font-style: italic;">I</span> knew?&nbsp; It's whether lots of <span style="font-style: italic;">other</span> people know.&nbsp; Lots of <span style="font-style: italic;">other</span> people don't know.&nbsp; Saying they can go and look is useless because why would they if they don't know about it?<br><br>If you still don't get it after that, then I give up.<br><br></span><span style="font-style: italic;" id="_ctl0_PostForm_Reply">Read my post again, will you? And rememeber that&nbsp; XmlHttpRequest
    can handle data in any format. Even binary. AJAX itself is just a
    buzzword. It doesn't have to use XML. And if you have Javascript on the
    receiving end, JSON makes a better format, 'cause it <span style="font-weight: bold;">is</span> JS. You can deserialize a chunk with a simple call to eval(). There. Did I really need to explain that?</span><br style="font-style: italic;"><br>A later post cleared that up and it's just poorly named.&nbsp; Though I'm surprised that XmlHttpRequest can handle other formats.&nbsp; I can imagine JsonHttpRequest and so on, but I would expect XmlHttpRequest to handle, well, XML.&nbsp; Sorry about that.<br><br>I move that we submit AJAX as a WTF, not because it's bad in terms of functionality, but because of it's everything-must-be-prefixed-with-XML-even-if-it-doesn't-use-it naming standard.<br>
  • mcguire 2006-02-22 17:05
    SurfMan:
    "If you know how to handle a hammer, don't think of everything as a nail...".
    <br><br><br>You know what they say, "if all you have is a hammer and a screwdriver, everything looks like a threaded nail."<br><br>
  • felix 2006-02-23 00:07
    johnl:
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">Erm... if you don't know about it, shouldn't you go take a look?</span><br><br>You really don't get it, do you?&nbsp; Who cares whether <span style="font-style: italic;">I</span> knew?&nbsp; It's whether lots of <span style="font-style: italic;">other</span> people know.&nbsp; Lots of <span style="font-style: italic;">other</span> people don't know.&nbsp; Saying they can go and look is useless because why would they if they don't know about it?<br></span>
    <br>
    <br>
    <span style="font-style: italic;">Why would the go and look if they don't know about it? </span>So
    they learn something new and potentially better, that's why. How can
    you keep up in this bussiness if you don't learn new things all the
    time?<br>
    <br>
    And if you mean that you're passing data along to people you don't
    know, and it has to be in a widely-known format... well... I
    understand, but then it can't be application-specific, can it? Because
    you'd have to give them documentation as well. Then you might as well
    choose any format.<br>
    <br>
    No, I don't get it... just give me an example.<br>
    <br>
    <span style="font-style: italic;" id="_ctl0_PostForm_Reply"></span>
    johnl:
    <br>A later post cleared that up and it's just poorly named.<br>
    <br>
    I noticed that after I posted, and I owed you a reply anyway. You're right about the name, but see above.<br>
    <br>
    johnl:
    <br>
    I move that we submit AJAX as a WTF, not because it's bad in terms of
    functionality, but because of it's
    everything-must-be-prefixed-with-XML-even-if-it-doesn't-use-it naming
    standard.<br>
    <br>
    <br>
    Good idea :))<br>
    <br>
  • Schol-R-LEA 2006-02-23 03:57
    <span style="font-style: italic;">Looks at today's WTF, cries<br><br></span>As for the XML thing, I still don't see why reinventing the s-expression in an awkward and verbose manner is such a big deal...
  • johnl 2006-02-23 06:31
    Ok, not quite ready to give up on that point just yet felix :P<br><br>Take me for example.&nbsp; Before it was mentioned here I didn't go to the JSON site because I didn't know it existed.&nbsp; I didn't read any books about it because I haven't seen any.&nbsp; I didn't read any blogs about it because I didn't see any (I don't subscribe to all the RSS feeds out there or visit all the blogs, and I don't get time to read everything on the ones I subscribe to or visit regularly).&nbsp; I didn't search google for it because, again, I didn't know it existed and I don't usually search for things that I don't know exist.<br><br>Most likely, you just don't like XML (wait! I'm not trying to flame you - read to the end) and wanted an alternative to it.&nbsp; Unsurprisingly, a google search for 'xml alternative' returns JSON as the 4th match.&nbsp; However, before today I didn't do this search because I didn't see the need to - I find XML quite workable, and I didn't even think "isn't there anything else I can use.<br><br>The problem with JSON isn't so much a problem with the system itself - it's a lack of publicity.&nbsp; If you want, think of it as VHS vs BetaMax.&nbsp; Not enough people bought BetaMax, even though it's widely accepted as the superior system.&nbsp; But if nobody buys it, then they don't make tapes for it, so anybody buying one becomes even more unlikely. <br><br>I'm not going to debate whether XML is better than JSON or vice versa, but XML has the advantage that everybody knows about it.&nbsp; If I want to exchange data with someone, they are more likely to be able to do something with XML than JSON because their tools are more likely to support XML already.<br><br>For this to change, JSON needs to encourage people to support it as an Import/Export format, it needs to get itself known.&nbsp; XML is practically a household name which is vital for an interchange format.<br><br>Hope that helps<br>
  • felix 2006-02-23 07:47
    johnl:
    <br>Take me for example.&nbsp; Before it was
    mentioned here I didn't go to the JSON site because I didn't know it
    existed. [...]&nbsp; I didn't search google for it because, again, I
    didn't know it existed and I don't usually search for things that I
    don't know exist.<br>
    <br>
    I don't even see how you could search for something you don't know
    exists. I happened upon it myself while looking for something
    unrelated. I didn't need it back then. But I learned about it because I
    could see it being potentially useful someday. Don't you do that kind
    of thing?<br><br>
    johnl:
    <br>
    Most likely, you just don't like XML (wait! I'm not trying to flame you - read to the end) and wanted an alternative to it.<br>
    <br>
    I did read to the end. It's not that I dislike XML. What I dislike is the one-size-fits-all approach.<br><br>
    johnl:
    <br>
    I'm not going to debate whether XML is better than JSON or vice versa,
    but XML has the advantage that everybody knows about it.&nbsp; If I
    want to exchange data with someone, they are more likely to be able to
    do something with XML than JSON because their tools are more likely to
    support XML already.<br>
    <br>
    I'm not sure one is better than the other. I wouldn't use JSON for
    documents with much text and little structure, just as I wouldn't use
    XML for object serialization. But to choose one over the other based on
    popularity? It's like buying a Ford (or whatever brand is popular in
    your country) because all your neighbours did, not because it's the
    best car for your needs. As for the Betamax, it <span style="font-style: italic;">was</span> popular. Among the professionals ;-)<br><br>
    johnl:
    <br>
    Hope that helps<br>
    <br>
    Yes it does. Let's move on to the next WTF.<br>
    <br>
  • johnl 2006-02-23 08:18
    <span id="_ctl0_PostForm_Reply"><span style="font-style: italic;">I don't even see how you could search for something you don't know
    exists. I happened upon it myself while looking for something
    unrelated. I didn't need it back then. But I learned about it because I
    could see it being potentially useful someday. Don't you do that kind
    of thing?</span><br><br>Of course I do, I just haven't happened on JSON as of yet.&nbsp; The chances that links to stuff that's unrelated (and whether I pay attention to those links - ads just kind of get ignored, for example) will turn up JSON seem quite small to me.&nbsp; I suppose if I was talking about representing data as text, as we are here, or I cast myself as someone particularly interested in the field, someone might mention it.&nbsp; But conversations such as "How's the weather, oh, BTW, try JSON" aren't all that common.<br><br>I'd be surprised if I was the only one who hadn't randomly come across JSON.<br></span><span id="_ctl0_PostForm_Reply"><br><span style="font-style: italic;">
    I did read to the end. It's not that I dislike XML. What I dislike is the one-size-fits-all approach.</span><br><br>Sorry, I didn't want to to think I was just calling you an XML-hater.&nbsp; I was trying to say "you hate XML, so you looked for something better", rather than "you hate XML so anything else will do". I was worried that you might just read the first part of the sentence, get pissed off because you thought I was saying the latter, and flame me.<br></span><span id="_ctl0_PostForm_Reply"><br><span style="font-style: italic;">
    I'm not sure one is better than the other. I wouldn't use JSON for
    documents with much text and little structure, just as I wouldn't use
    XML for object serialization. But to choose one over the other based on
    popularity? It's like buying a Ford (or whatever brand is popular in
    your country) because all your neighbours did, not because it's the
    best car for your needs. <br><br></span>No it's not.&nbsp; Buying a car is different because your choice of car doesn't affect anyone else.&nbsp; If you really want to take the car analogy, it's like driving on one particular side of the road, just because that's what everyone else does.&nbsp; ;)&nbsp; (I invite you to drive on the wrong side - whichever is the wrong side in your country - and see what happens.)<span style="font-style: italic;"><br><br>As for the Betamax, it was popular. Among the professionals ;-)<br><br></span>Professionals aren't the majority.&nbsp; If the pros use Betamax and everyone else uses VHS, then VHS is more popular.<span style="font-style: italic;"><br></span></span>
  • Otto 2006-02-23 12:38
    masklinn:
    <span id="_ctl0_PostForm_Reply"><br><p>Using raw JS object notation still is much easier (and usually more readable) than using the DOM interface to extract data from the XML document. Or so I think.</p>
    <br>"More readable" I would agree with, but "easier" I would argue against, since the code is usually pretty identical both ways, you're just referencing elements directly with JSON and using functions to reference them with the XML DOM. It's really not all that different in the actual code, although the direct approach is more intuitive and readable.<br><br>But for the case where you're pulling down data and then stuffing bits from it onto a webpage (not an uncommon case), XML is significant easier and more readable if you are using XSLT to do it, because in that case it's reduced to a few functions. Read in the XML and XSL, run them through transformXML, shove the output to a div somewhere. It takes a bit more thought in the design, but it's also significantly faster in IE (thanks to the transformation running as native code), though it admittedly can be slightly slower in Firefox. For a lot of what AJAX type stuff tends to do, this fits the model well. Not always, I grant you, and XSL itself is a WTF and a half, but it works once you get used to it.<br><br>They both work well in different cases, and you really can't say that one of them is better in every case.</span>
  • masklinn 2006-02-23 13:54
    Otto:
    But for the case where you're pulling down data and then stuffing bits from it onto a webpage (not an uncommon case), XML is significant easier and more readable if you are using XSLT to do it

    <p>But you can't. Because only two browsers support client-side XSLT. So you're basically left with 3 choices, not giving a flying fuck about other browsers (duh), implementing everything twice, once with and once without XSLT (with two code paths to maintain), or implementing everything without XSLT.</p>
    <p>I don't quite see the point of the second choice, and the first one would only be acceptable in a controlled environment (LAN/WAN).</p>
  • masklinn 2006-02-23 13:58
    <p>Precision: client-side XSLT meaning, in this case, JS API to the browser's XSLT processor. Safari can apply XSLT files to XML files but doesn't provide any JS API, and Opera 8.5 doesn't provide said API yet, even though I think the soon-to-be-released Opera 9 does.</p>
  • Otto 2006-02-23 15:33
    masklinn:
    But you can't. Because only two browsers support client-side XSLT. So you're basically left with 3 choices, not giving a flying fuck about other browsers (duh), implementing everything twice, once with and once without XSLT (with two code paths to maintain), or implementing everything without XSLT.
    <p>I don't quite see the point of the second choice, and the first one would only be acceptable in a controlled environment (LAN/WAN).
    </p><p>True as far as it goes, although there do exist javascript implementations of XSLT (Google's AJAXSLT, for example). I wouldn't recommend them for prime-time use, because they are slow, but they work.</p><p>However, client-side XSLT is in use on a number of different live web-sites. They simply don't support Safari (or Opera until Opera gets around to 9). So I disagree with the controlled environment notion. For all intents and purposes, the web that can do AJAX and such other functionality consists of two browsers: IE and Firefox. Safari is not supported by lots of websites and it likely won't be until they add that sort of thing. Lots of Mac users just install Firefox anyway because of the lack of Safari support on all the newer websites. Or rather, if Safari works it's because of luck as opposed to intent.</p><p>In any case, Safari is not on my own list of test cases, nor will it probably ever be. Looking through various logs, Safari users comprise less than 1% even on the pure HTML sites I can see logs for. It's simply not a big enough market to worry about, IMO.<br></p>
  • Enric Naval 2006-02-24 05:05
    masklinn:
    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

    <P>Actually, they'll probably use that XQuery bullshit, the wonderful Tamino database already does it (native XML database for the win, XQuery or XQL requests (with heaps of XPath goodness... the parts that've been implemented in the DB engine i mean), runs slower than molasses and overall defeats the very purpose of a database).</P>
    <P>But at least you can run XSLs on the raw data you retrieve from the DB without having to do any transformation!</P>
    Anonymous:
    Someone needs Tamino - http://www2.softwareag.com/Corporate/products/tamino/default.asp<BR><BR>It's an XML database. Yes I've had the misfortune to use it...<BR><BR>CAPTCHA : bozo - Hmmm....<BR>

    <P>Oooh, another guy who's had the (dubious) priviledge of "using" Tamino, I'm not alone!</P>


    <p>A european level project with european news agencies involved...</p>

    <p>... using a XML database (Firebird?), data processing, server-client communication....</p>

    <p>... when the client and server code are mostly finished and functioning, they attempt to place the distributed application in production....</p>

    <p>.. when the XML database is holding more than 300 news, it starts going sllllooooooooooooooooowwwww....</p>

    <p>... just when they have discovered the problem, they get their finantion cut because of project director's problems with justice...</p>

    <p>... so they never get to rewrite the whole thing to use a relational database and relegate XML for inter-application communication :(</p>

  • johnl 2006-02-24 07:13
    Masklinn, you realise that you can apply an XSL on the server, right?<br>
  • masklinn 2006-02-24 08:45
    johnl:
    Masklinn, you realise that you can apply an XSL on the server, right?<br>

    <p>Yes, and I realise that this is absolutely not what Otto was talking about, too.</p>
  • Enric Naval 2006-02-24 17:56
    Anonymous:
    Thats...not really that bad...<BR>Seriously, I've done far worse things in SQL and I've known the language less than 3 months<BR>Try UNIONing 3 statements each 6 lines long, reading from tables with different column names for the same data and each statement requiring 2 SELECTs in their FROM list because the unindexed lookup table otherwise gets overly linked and sends the execution time to hell... That statement only reached 3 SELECTs deep(the third was so that I could order the whole lot) and I found it relatively easy to maintain weeks after I had written it.<BR><BR>If you think SQL is bad, try dealing with VB... The only reason my statement was so long was because it'd be agonizing to bring the data back and do all the transformation on the local computer in Excel for Applications... -.-'<BR>


    <p>Wow. Are you masochist or something? :)</p>

    <p>I now refuse to work with anything barely resembling VB, windows or office because they require that sort of kludges because of their limitations. Very specially Access. Gimme mysql or postgres, even if I can only use the command-line client.</p>
  • Norman H 2006-02-24 20:13
    Amen!
  • KennyBoy 2006-02-27 04:56
    <P>Sitara?</P>
  • unklegwar 2006-04-21 16:15
    I worked with an e-store package that did this for addresses. It was all fine until we needed to modify the code to search addresses by zip, state, name, etc.<br><br>When we got that requirement and realized the implication, much "WTF" was uttered. <br><br>I work someplace else now :-)<br>
  • theshowmecanuck 2006-09-15 18:50
    <p><em>
    Maybe they were concerned that their database might become over-normalized.&nbsp; <strong>Everyone</strong> knows the danger of an over-normalized database, I&#39;m sure.</em></p><p>&nbsp;I know you were being sarcastic, but in truth, sometimes it can be over normalized (depending on the application).&nbsp; That is why people sometimes need to de-normalize a schema... usually when you end up having to do a large number of joins to retrieve your data for a high demand application (even with the chance of data redundency).&nbsp; Data warehousing can be thought of from one perspective (sometimes) as denormalized data.&nbsp; Yeah I know, it is really &#39;better optimized for retrieval&#39;... but that is why you would denormalize.<br />&nbsp;</p>
  • Zetetic 2006-09-17 03:26
    <p><em>
    I am certain that the guy who came up with this plan was immediately promoted to management.</em></p><p>&nbsp;</p><p>Good. That way he will do less damage.&nbsp;</p>
  • Kent 2008-04-07 05:16
    Cowboy Bob:
    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....