• (cs)
    Directive 595 Part 4. "Databases and database languages are slow give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution"

    From this point forward, all data will be in XML format. It is more enterprise-y

  • (cs)

    And least there's a happy ending - the power-mad dictator is run out of office and a hopefully benevolent one put in his place.

  • (cs)

    Cool story, except what kind of architect goes off line for two weeks straight? Surely someone at least called his cell phone?

  • (cs)

    Directive 595, Part 5:

    Flat files.

  • My Name Is Missing (unregistered)

    Directive 595 Part 4 would make a good science fiction movie.

    I once worked in a place with a madman like that. Not for long.

  • Rosuav (unregistered)

    The thing that worries me most: What were the other five hundred and ninety-four directives?

  • Up Down (unregistered) in reply to trtrwtf
    trtrwtf:
    Directive 595, Part 5:

    Flat files.

    You mean:

    Non flat files give lack of flexibility, more costly
evolution, inhibit the use of the database acting as a
service to applications and make it an inhibitor to evolution.
  • kikito (unregistered)

    Oh I know.

    Replace all strings in the database with integers.

    Integers are more efficient to lookup and compare.

    All strings will be looked up in a single indexed database.

  • nag-geoff (unregistered)

    Evolution is over-rated.

    The foreign key part is something I would agree with. There is no point in having foreign keys. They are as useful as the foreigners in my country.

  • (cs)

    F**K!!!! I read all the way to the end and you left me hanging? That is like what I would imagine the reaction the average 40-year-old soccer mom had at the end of the latest Twilight!

    (I deny having seen it.)

  • (cs) 
    Please refer to Directive 1. 
"A directive is such that all reasonable discussion has taken place and as such is not open for debate."
    Clearly not all reasonable discussion had taken place, since Daniel had reasons for discussing the issue further.
  • Taki (unregistered)

    Directive 595 Part 4 is as follows.

    "Typed database columns give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please change all database columns to type VARCHAR2(4000).

  • Anonymous (unregistered)

    Part 4 is: Tables give a lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make evolution more difficult. All tables are to be replaced with a single table of key-value pairs.

  • (cs)

    Reminded me a little of Francisco d'Anconia in Atlas Shrugged. I can not immediately think of a more subtle and comprehensive way of sabotaging a database if one were to do it deliberately.

  • (cs)
    ...the table filled up with duplicate data.
    Oh good, now we know what part 4 was going to be: 
    Directive 595 Part 4 is as follows.
  "Existing production data give lack of flexibility, more 
   costly evolution, inhibit the use of the database acting 
   as a service to applications and make it an inhibitor to 
   evolution."
As such, please remove from all production databases.
  • (cs)

    "No chief architect has ever made a mistake or distorted information. We are all, by any practical definition, foolproof and incapable of error."

  • geoffrey (unregistered)

    Perhaps the next directive would have been to go back to VSAM, which would have actually solved all these problems anyway.

  • nag-geoff (unregistered) in reply to DCRoss
    DCRoss:
    "No chief architect has ever made a mistake or distorted information. We are all, by any practical definition, foolproof and incapable of error."

    Clearly the chief architect was a hacker employed by the rivals.

  • syskill (unregistered) in reply to Taki
    Taki:
    Directive 595 Part 4 is as follows.

    "Typed database columns give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please change all database columns to type VARCHAR2(4000).

    That was my guess too.

  • Alex (unregistered)

    Dear Database Architects and Administrators,

    Directive 596 is as follows.

    "Database Architects and Administrators give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please remove yourself from the server room.

    Sincerely, Chief Architect Gerald

  • Excelsior (unregistered)
    "Foreign and Primary Key constraints give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."
    I have serious doubts about this story being possibly true... Heck, I can't even read that sentence without laughing.
  • (cs)

    Changed it straight into production! Says alot about his work as application administrator. He should've known better already.

  • (cs)

    These guys should've used an ORM. It would have prevented all these problems and eliminated the position of Database Architect.

  • (cs) in reply to ooblek
    ooblek:
    F**K!!!! I read all the way to the end and you left me hanging? That is like what I would imagine the reaction the average 40-year-old soccer mom had at the end of the latest Twilight!

    (I deny having seen it.)

    I agree - don't leave us hanging - what on Earth was the next directive?

  • (cs) in reply to Taki
    Taki:
    Directive 595 Part 4 is as follows.

    "Typed database columns give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please change all database columns to type VARCHAR2(4000).

    Or convert the database to SQLite.

  • (cs) in reply to snoofle
    snoofle:
    I agree - don't leave us hanging - what on Earth was the next directive?
    “All delegates are entitled to exactly one car parking space unless special dispensation is granted by the Car Lot Management Committee.”
  • (cs) in reply to dkf
    dkf:
    Taki:
    Directive 595 Part 4 is as follows.

    "Typed database columns give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please change all database columns to type VARCHAR2(4000).

    Or convert the database to SQLite.
    Or Amazon SimpleDB.

  • (cs) in reply to frits
    frits:
    dkf:
    Taki:
    Directive 595 Part 4 is as follows.

    "Typed database columns give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please change all database columns to type VARCHAR2(4000).

    Or convert the database to SQLite.
    Or Amazon SimpleDB.
    Or MongoDB

  • Arnold Judas Rimmer (unregistered)

    Quarantine Mr Flibble doesn't like indexes either.

  • LANMind (unregistered) in reply to nag-geoff
    nag-geoff:
    Evolution is over-rated.

    The foreign key part is something I would agree with. There is no point in having foreign keys. They are as useful as the foreigners in my country.

    You obviously don't know anything about ORM tools. If you look it up, it might make your day.

  • Hortical (unregistered)

    Daniel should not have questioned the Chief Architect as no business can run with subordinates always contradicting superiors and disobeying directives. If you think it was okay for employees to act this way, or to quit when they don't appreciate an order they've received, you must know nothing about business. You get paid to do your job, not hold technical debates to satisfy your own ego.

    Further, Daniel should have been immediately fired for being away from the company while it was in crisis. And why wasn't he there to offer his advice to the Chief Architect when it would have prevented this disaster?

  • R. Watkins (unregistered)

    Sadly, I was moved into an application group that would agree with this thinking. They never bothered to write it down, of course - or use version control, but I digress. We have minimal indexing. Indexing is just overhead that slows a database down. We don't use sequences, we use triggers that build a hash from the data and uses that instead. Sometimes the data that was used to build the hash changes and you can get collisions, but nothing a quick production data tweak can't fix. It took me several months before I had a full day where I didn't learn some new travesty.

  • George Boole (unregistered)

    bool shit = true;

  • Tim (unregistered)

    Sorry I'm calling bullshit on this one. Were a person with this level of responsibility to act in such a ridiculous manner, I'm sure one of his subordinates would have gone straight to the CTO or CEO

  • YF (unregistered) in reply to The poop of DOOM
    The poop of DOOM:
    frits:
    dkf:
    Taki:
    Directive 595 Part 4 is as follows.

    "Typed database columns give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution."

    As such, please change all database columns to type VARCHAR2(4000).

    Or convert the database to SQLite.
    Or Amazon SimpleDB.
    Or MongoDB
    Or Access.

  • (cs)

    How about something like this:

    Dear Database Architect:

    Directive 595 Part 4 is as follows:

    In case you can't tell, this is a grown up place. The fact that you insist on not following my orders to the letter clearly shows you're too young and stupid to be working here.

    Go away and grow up.

    Sincerely, Chief Architect Gerald "Bert" Glanstron

  • Jens (unregistered)

    And with all this free time on hand Gerald built the first NoSQL database.

  • nag-geoff (unregistered) in reply to frits
    frits:
    These guys should've used an ORM. It would have prevented all these problems and eliminated the position of Database Architect.

    Normally I would agree with you on that. The ORM is a scare tactic used primarily by java developers to scare the database guys into thinking that they "the database guys" are no longer relevant in today's world. Microsoft has also caught onto the act. AN ORM ELIMINATES THE NEED FOR database administrators, but it STILL NEEDS someone to make decisions. At the very least, the CHIEF ARCHITECT would have left the ORM system alone.

    causa: it hurts when it happens.

  • Jack Foluney (unregistered)

    This story seems like it's made-up. It's funny though. Surely no one is that stupid are they??

  • Trish (unregistered) in reply to BentFranklin
    BentFranklin:
    Cool story, except what kind of architect goes off line for two weeks straight? Surely someone at least called his cell phone?

    A sensible one who wants to resign anyway... I know enough people who have two cellphone-numbers, and one of the numbers is only given to a close circle of family-and freinds ans STRICTLY non-work. Might be frowned upon, but works miracles for being able to actually relax on holidays ;)

  • Arne (unregistered) in reply to nag-geoff

    Oh, You started to appreciate about the foreigners in Your country? Or was it just plain thoughtless?

  • (cs)

    I used to work in a team where all the FORTRAN (it was a long time ago) was compiled without any bounds checking enabled. The only time we every compiled anything with bounds checking was when the data had been terminally hosed through out-of-array-bounds errors caused by someone incompetent mucking it up (strangely, this wasn't always me). The amount of time saved by the code running more quickly with bounds checking disabled was more than offset by the fiddling around fixing the problems caused by the adoption of such a strategy.

  • Darth Spammicus (unregistered)

    And here I expected it would be Grand Army of the Republic Order 66.

    CAPTCHA: aptent - What you put up over a collection of applications at a flea market.

  • Tom (unregistered) in reply to The poop of DOOM

    Microsft Access. On a web server.

  • callcopse (unregistered)

    I liked this one. It had many classic elements. To be honest I would call BS myself if I hadn't met people with a similar understanding of data integrity myself and heard similar words coming from their mouths - a slight stretch to imagine them issued by someone who has got as far as 'Chief Architect' but relatively plausible - power does funny things...

    More than the robot than flung and caught stuff anyhow.

  • Dazed (unregistered) in reply to Trish
    Trish:
    I know enough people who have two cellphone-numbers, and one of the numbers is only given to a close circle of family-and freinds ans STRICTLY non-work. Might be frowned upon, but works miracles for being able to actually relax on holidays ;)
    I have a simpler and more reliable solution for relaxing on holidays - it's called an off switch.
  • JayC (unregistered) in reply to ParkinT
    ParkinT:
    Directive 595 Part 4. "Databases and database languages are slow give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution"

    From this point forward, all data will be in XML format. It is more enterprise-y

    People have apparently done just that.

    Askmet sucks.

  • Tom (unregistered) in reply to nag-geoff
    nag-geoff:
    Evolution is over-rated.

    The foreign key part is something I would agree with. There is no point in having foreign keys. They are as useful as the foreigners in my country.

    Foreign keys are useful for data mapping and self-documentation, and they can also help programs automatically do things like dereference code table values to their text values.

    While they're not actually required, they should be used whenever possible, so a future developer doesn't have to scratch his head and "wtf" when trying to find a foreign key mapping that doesn't make obvious sense.

    As to PRIMARY keys... well, I guess you could get away with simply indexing a table's identity column, but something tells me that "Part 4" is going to have something to do with the removal of all indexes.

  • forgottenlord (unregistered)

    When the database lead has not had a chance to give his input on the reason for a philosophical change of database design, you have not had sufficient input to render a decision.

  • Bill C. (unregistered) in reply to ParkinT
    ParkinT:
    Directive 595 Part 4. "Databases and database languages are slow give lack of flexibility, more costly evolution, inhibit the use of the database acting as a service to applications and make it an inhibitor to evolution"

    From this point forward, all data will be in XML format. It is more enterprise-y

    If you've already abandoned the strengths of a relational database, why not? At least you can prevent data collisions by keeping things in different files.

Leave a comment on “Directive 595”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article