• 3stdev (unregistered)

    <customerDefinedField>Frist!</customerDefinedField>

  • bvs23bkv33 (unregistered)

    In the beginning of the movie I was sure that Titanic will sink. So it did. Somehow, in the beginning of this story, I was thinking that they were declaring and reopening new cursor to fetch every next row. But they didn't.

  • my name is missing (unregistered)

    We just replaced something that looked very similar. Why is storing giant XML documents in a relational database a pattern used by anyone other than third-world dictators?

  • Brian (unregistered) in reply to my name is missing

    Well, in my experience, enterprise bureaucrats do seem to have a lot in common with third-world dictators...

  • Zach (unregistered)

    WTAF - the more I read this, the more I decided that this sounds like fantasy or something in the movies. If I will it enough, then maybe that thought will come true

  • dpm (unregistered) in reply to Zach

    "Fantasy" my [not]shiny [not]metal ass. I began work at a place once and quickly saw that the arrogant developer in charge used blobs. I adamantly refused to work with that and ended up on a new project, but oh yes indeed this is real.

  • (nodebb)

    XML without a schema? From what I've seen, that's the norm, having one makes you a pariah.

  • Anoooniemus (unregistered)

    I've literally left a job this year where they IMPLEMENTED this end of last year, and it was an improvement of their current situation. They also used SQL Server and did not opt for the XML supporting storage, no it was stored as blobs.

    I never took these Senior developers seriously, I already did not since working with them a few times pointed out they were not just slow by being careful. They just were incompetent.

  • Anoooniemus (unregistered)

    To add, as I can't edit this.

    This is a Major Health Tech company and I have lost all respect for this company.

  • (nodebb)

    Brought to you by the "XML is just text anyway" department. And oooh boy, that brought back wild memories of my past project where in the name of "pluggability", all the business (in our case, health-related) data was stored in XML in (what else?) CLOBs in Oracle (because "yes we know that there's the XMLTYPE in Oracle, but..but.. something something dev DB initializing scripts with INSERTS, something...") To add insult to injury, we had tables with BLOBs as well. With SWFs in them. Loaded and ran at runtime by the "core" application. [distant screaming noises]

  • Mason Wheeler (unregistered)

    As an enterprise product, the messaging system prizes configurability and customizability over utility, performance, and common sense. It's not designed to solve a problem, but instead to allow customers to solve problems they didn't know they even had, mostly by inventing them.

    Anyone else read that and immediately think of Unity3D?

  • Mike Swaim (google) in reply to my name is missing

    At the last place I worked, data was stored in big text files (almost XML). I talked with one of the designers, and he said that by doing it that way, they could change their schema however they liked without going through the DBAs (who they hated). He also admitted that it was a mistake. That system was featured here over a decade ago. The best part was that because other systems needed their data, their data was replicated in two other databases with normal schema, for the rest of us.

  • (nodebb)

    some PM at a three-branch bank in East Pilsbury decided they wanted a new field in their chatroom and it happens to collide with one of the fields we already use.

    ((naive))Isn't that what XML namespaces are for?((/naive))

  • Little Bobby Tables (unregistered) in reply to CoyneTheDup

    Ha-ha, well it starts without a schema, then when I've done the job, I pass it through an online tool which automatically generates a schema for it. Hence my boss thinks I've been good and designed it properly with a well-designed and neatly laid out schema, and so now I have a reputation for being a wizard with XML. FML more like.

  • gumpy_gus (unregistered)

    Reminds me of a major student class signup app at a major university. The administration was sold on the idea of buying a $7 million dollar IBM mainframe to run student registration.

    But the java coders they used were less than efficient, that expensive mainframe would wilt with just 10 simultaneous registration sessions.

    A quick peek at the code showed many infelicities, like when displaying a class schedule, the app did SQL queries to get the names of the days and months, (just in case the name of July ever changed). The java code had never been tested with more than one user, so to get multi-user ability, they put the word "synchronized" in front of each method. So it was slow, real slow.

  • snoofle (unregistered) in reply to gumpy_gus

    "...So it was slow, real slow"

    I'll play; How slow was it?

  • Dave (unregistered)

    The behaviour in the article makes perfect sense from a business point of view, given that they're charging consultants out by the day to sit there and wait for the job to complete.

  • gumpy_gus (unregistered) in reply to snoofle

    Well it was supposed to handle 600 simultaneous users, it could actually barely handle 10.

  • (nodebb)

    This was outsourced to Manila. And I know this because the log files for a particular module of our ERP -- which was outsourced to a company in Manila -- contain entries as XML files stored as CLOBs.

    Log files. Transaction log files. So, if there's a database issue, logging throws an exception, but it can't be logged. Because log files live in the database.

  • Olivier (unregistered)

    "If we did that, then our customers couldn't make up their own XML keys, and then add their own procedures in our proprietary scripting language which reads them, and then I wouldn't constantly get tickets because some PM at a three-branch bank in East Pilsbury decided they wanted a new field in their chatroom and it happens to collide with one of the fields we already use."

    Something is not right in the citation above. If you are using a proprietary scripting language, that language certainly knows how to differentiate between the keys belonging to the core software and to the user. And that language certainly encapsulate the key names such a way that the could not be collision.

  • (nodebb) in reply to Steve_The_Cynic

    ((naive))Isn't that what XML namespaces are for?((/naive))

    When done right, yes.

    So that's an incredibly uncommon event in Enterprise Systems, except for when it adds so much software bureaucracy to make things even more painful.

  • Tom (unregistered)

    A similar situation made me quit a previous job. Storing all your data in xml fields, or even worse blobs, tends to make something as simple as running a query over the data a nightmare. "But now they can configure things themselves"... yeah right, give them the tools to hang themselves, that will make them happy.

  • (nodebb) in reply to Olivier

    "If you are using a proprietary scripting language, that language certainly knows how to differentiate between the keys belonging to the core software and to the user."

    What's the precondition for creating a proprietary scripting language? You must be stupid. Very stupid. Really very stupid. And guess, when that precondition is met, how will that result in a language which "knows how to differentiate between the keys belonging to the core software and to the user"?

  • robby the robot (unregistered)

    For a long time XML was seen as the solution to everything, in the same way that Blockchain is now, and some companies unfortunately based their products around it.

  • Haggishunter (unregistered)

    Nice to see CLOBs being referred to as CLOBs instead of "Character Clobs".

  • Paul Neumann (unregistered) in reply to Haggishunter

    Not "Character Clobs" -- Binary CLOBs and Character BLOBs

  • (nodebb) in reply to my name is missing

    Because they're stupid.

    I watched a system that does this be developed. They use XML as their only in/out parameter to stored procedures and archive almost every transaction message that passes through the system. But wait, that's not all! Every change is "audited" too. So there's a trillion line field-old-new-user-date table. Then there's another copy (not a view, a straight up copy) flattened out into "audit" rows. Did I mention that something like half of the dates are stored as long form text too, this fine Friday, November 9th, 2018 at 6:40 AM?

    And then they just can't figure out why this abomination has been triggering disk space alerts for the last two years.

  • markm (unregistered)

    @gumpy_gus: "the app did SQL queries to get the names of the days and months, (just in case the name of July ever changed)"

    Was this app sold in other countries? To a SQL programmer, the simplest way to implement internationalization would be to look up everything that might change in a SQL database. OTOH, to an old hand like me, the simplest way would be to parse a JSON file into a well-organized structure in memory when your program fires up, and then all those look ups are just de-referencing pointers and indexing.

  • Ola (unregistered)

    Elisabeth is my favorite character!

  • Old dude (unregistered)

    Storing schema-less data in XML in SQL Server is no different from storing schema-less JSONs in Mongodb. Why the latter is all cool and shiny and the former is frowned upon? WTF with TDWTF?? easy improvement for this scenario is to 1) add schema to xml type column 2) index (if needed) 3) use xquery to update fields in xml. it will run in seconds

Leave a comment on “Enterprising Messages”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article