• Scourge of Programmers (unregistered)

    Hasn't their "smart" Dba heard about storing values in the power of two's?

    Then you could use BIT arithmetic to get the value you want.

  • Scourge of Programmers (unregistered)

    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

  • Anon (unregistered)

    Trying to capture something as open-ended as "hobbies" in a database is a fools errand. You could never cover every perverted thing people might be into. But you really don't need to. You might care is somebody is into photography (if you sell cameras), but who gives a shit if somebody is into medieval history? If you don't sell books on medieval history?

    So just drop the "hobbies" thing altogether and just have a series of "rate your interest in this topic" questions for things that you can actually do something with. There are even subtler ways you might gauge interest in subjects without explicitly asking too. For example, if your website has pages on cameras and a user visits those, they are hinting that they are interested in cameras!

    If you really must, include a free text field for other interests and then mine it for recurring words that might hint and other interests you can add later.

  • Anon (unregistered) in reply to Scourge of Programmers
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    Great. Because we all know there are only 64-bits (or chose whatever limit your database supports) of hobbies out there.

  • Black Bart (unregistered) in reply to Anon
    Anon:
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    Great. Because we all know there are only 64-bits (or chose whatever limit your database supports) of hobbies out there.

    Simple - store the bit field as a binary image blob that can expand to any number of bits!

  • Paul Neumann (unregistered) in reply to Krunt
    Krunt:
    Because DBAs shouldn't be developing, designing, or architecting programming solutions. They should be administering databases, tuning queries and indexes, monitoring storage and assisting devs where necessary. I'd much sooner hire a DBA who knows the ins and outs of SQL backup than one who (thinks he) knows the finer points of a join statement.
    Let me know how that works out once you figure out how to avoid the self-contradiction.

    Let management dictate the WHAT, let the dev develop the logical HOW, let the dba administer HOW the data which needs persisted is. This should indicate a close relation between dev and dba. (And contention with management.)

  • Breezey145 (unregistered) in reply to oheso
    oheso:
    The end of the story makes no sense. They've got a table of hobbies. They create a new table of hobbies. Then they use the original table of hobbies.

    The only difference between that and Luigi's proposal is the many-to-many relationship. With the DBA's (existing) set-up, there's only one hobby per client.

    The DBA's final remark about not having to add a foreign key is a non-sequiter, as he's already got the foreign key.

    Yeah, and the way it was written was very anti-climactic, just kind of stopping. If all the hobbies are in a table, then... ah to hell with it. I mostly just come for the Hanzo stories myself.

    TRWTF was the change order submitted in paper instead of in a change control system.

  • Mike (unregistered)

    So fishing (0001) + fishing (0001) = photograpy (0010)

    (I like fishing a lot)

  • Tommy Phillips (unregistered) in reply to Meep

    Right on the money. I can't describe the despair when I heard of a manager in our organization who decided to use Hibernate because "that way, the developers don't even have to know SQL!"

    Just guess which part of the application now causes the most problems for both the database and the application server.

    CAPTCHA: dolor: I'll give you a dolor for every developer you hire that understands SQL.

  • Ol' Bob (unregistered) in reply to Norman Diamond

    Nein! Zis is KAOS!! Ve don't "CONTROL" here!!!

  • Ol' Bob (unregistered) in reply to Scourge of Programmers
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    The "values-encoded-as-powers-of-2" trick? That's the third time I've fallen for that one this week!

  • caper (unregistered)

    I knew we were in trouble when I saw the table which has a name that starts with tbl_.

    On the other hand. If there really are only 4 hobbies to choose from it might be a reasonable solution because it gives sales people a simple list to look at.

  • Tasty (unregistered) in reply to Scourge of Programmers
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    There's a finite, rather-small, limit to bit-masks. Why do we want to limit the number of hobbies that sales uses?

    Disk space AND I/O are way too cheap today. We can easily fit a a table of hobbies and a (hidden) join-table for the many-to-many.

    I think the real issue here is that it takes combinatorics to fill the DBA's hobbies list. Enumerate all "N choose I objects.", which is way larger than a sparse join table!

  • belzebub (unregistered) in reply to caper
    caper:
    I knew we were in trouble when I saw the table which has a name that starts with tbl_.
    Actually, using prefixes for tables, indexes, constraints, packages, views, etc. is quite reasonable naming convention if you work with oracle.
  • CigarDoug (unregistered) in reply to Breezey145
    Breezey145:
    TRWTF was the change order submitted in paper instead of in a change control system.
    This IS a change control system. Mr. Martinet can control the submission of changes by forcing the developer to come to his office and see their reaction as he hands him back the request with red ink all over it. It is much more dramatic than reading "rejected" on a computer screen. The screen probably wouldn't even say "rejected" in red text, much less a larger font. Thus, the developer is discouraged from submitting more change requests in the future.

    Now, that's control.

  • C-Derb (unregistered) in reply to ObiWayneKenobi

    Reading Comprehension Fail #1 and #2:

    ObiWayneKenobi:
    Ben:
    Luigi's solution was mad. This should be a free-text field with a pre-defined list of common values.
    Quite true. Something like hobbies which can be anything and everything, doesn't need some kind of corresponding lookup table, it needs the ability to enter anything with some kind of "smart" dropdown (like Google search) that prefills possibilities as you type it.
    Reading Comprehension Fail #3:
    Anon:
    Trying to capture something as open-ended as "hobbies" in a database is a fools errand. You could never cover every perverted thing people might be into. But you really don't need to. You might care is somebody is into photography (if you sell cameras), but who gives a shit if somebody is into medieval history? If you don't sell books on medieval history?
    All you guys missed this from the article:

    The Article:
    On his first day, Luigi was handed a simple looking request. The sales team wanted to collect data from customers about those customers’ hobbies. There was a predefined list, but the sales beasts wanted to be able to manage the list of hobbies themselves.
    It is what the customer asked for, dumb as it may be.
  • anonymous (unregistered) in reply to Ol' Bob
    Ol' Bob:
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    The "values-encoded-as-powers-of-2" trick? That's the third time I've fallen for that one this week!

    It's actually the scheme I'm using in a Sudoku app I'm in the process of writing (y'know, to represent a cell with multiple potential values i.e. pencil markings), but I definitely won't be exceeding the limitations of 64-bit integers for that...

  • Anon (unregistered) in reply to Mike

    At least then, you'd have a photo of the one that got away!

  • Anon (unregistered) in reply to Mike
    Mike:
    So fishing (0001) + fishing (0001) = photograpy (0010)

    (I like fishing a lot)

    "At least you'd have a picture of the one that got away!"

    Feh! Stoopid magic mouse.

  • OracleIsTheRealWTF (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    I've noticed that generally DBAs are over protective. They're extremely paranoid people that are afraid to relinquish any bit of control to anyone other than themselves. And organizations tend to be extremely paranoid as well, fearing anything that might let someone WHOM THEY HIRED do something that isn't specifically detailed in some manifest somewhere. This also tends to lead to nonsense like tracking each and every specific change that someone does, to the extent of even tracking when someone views a record, because they're so paranoid that somebody might change something instead of oh I don't know, trusting people they employ.

    it's not always large companies, either. I've seen an increasing amount of smaller organizations trying to pull the same rigid control like everyone else. The only thing I can think of its that they are run by old fuddy-duddys that are out of touch with the world since the last time they actually worked in an organization before making their own, so they keep the old outdated practices that were in place that they remember and are afraid to evolve.

    Yes, we're over protective. It's mainly because our systems are supposed to run at top performance, all the time. I know when one little thing runs 0.01 seconds too long I get called about it. Well, when you consistently introduce change in an environment like that, you lose consistent performance. Fact. We are overprotective because developers and the business are the first people to call "database" as an issue, not the fact their cursor inside a cursor inside a cursor doesn't scale well... well, it did against their 3 test records, it ran in 0.002 seconds...

    Captcha: jumentum, This is my friend Bob, have jumentum yet?

  • Nick (unregistered) in reply to Sarah
    It may look like a ManyToOne but that is only a mask to a hidden ManyToMany.

    This. Business logic (and reality) defines relationships between "things". Databases define relationships between tables. If the relationships defined in the database are not isomorphic to the relationships needed by business then it is usually the business logic that wins, requiring someone somewhere to reimplement a native database functionality outside of the database, as was done here.

  • (cs) in reply to Scourge of Programmers
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    Wrong bit for Killing Zombies. The Killing Zombies bit should be the SIGN bit. You got to be negative to kill the undead!

  • Anon cow (unregistered) in reply to Refro
    Refro:
    int_id str_hobbyies

    1 fishing

    2 photography

    3 dancing + photography

    4 climbing

    5 climbing + fishing + photography

    6 FileNotFound

    7 Writing C++ code

    8 ??

    9 Profit

  • Kanitatlan (unregistered)

    Now all we need is for Sales (who have asked for the authority) to decide to put in all the hobbies they can think of - after all what could go wrong.

    (for those without the Math, their look up table has 2^N records for N hobbies - 100 hobbies equals a mere 1 million records, I bet they can get to more than that)

    So in a bit we should get the new improved WTF from the hapless maintenance geek who is assigned the job of speeding it up.

    Obligatory captcha comment: We who are about to die "saluto" you

  • Jeremy (unregistered) in reply to Anon
    Anon:
    Scourge of Programmers:
    Store hobby values in this fashion. 1 - Climbing 2 - Photography 4 - Dancing 8 - Fishing 16 - Hunting 32 - Killing Zombies

    then store values as their SUMS. So for a person who love killing zombies and dancing. store 36 against his id.

    I hope the current crop of programmers knows about this time-saving valuable technique.

    Great. Because we all know there are only 64-bits (or chose whatever limit your database supports) of hobbies out there.

    Not to mention it's still working really hard to avoid the obvious solution. Yes there are "better" ways to do this table into one field thing, but it still doesn't explain why the obvious way should be avoided, especially in this case, where they made a new table for managing the combinations anyway.

    You'd swear some DBA/programmers think new tables/fields come out of their paycheck.

  • (cs) in reply to belzebub
    belzebub:
    caper:
    I knew we were in trouble when I saw the table which has a name that starts with tbl_.
    Actually, using prefixes for tables, indexes, constraints, packages, views, etc. is quite reasonable naming convention if you work with oracle.

    It's not one of those things that's really good or really bad, but it can be helpful. TO say that it's a really bad idea is probably the worst approach that you can take to it.

  • (cs) in reply to C-Derb
    C-Derb:
    All you guys missed this from the article:
    The Article:
    On his first day, Luigi was handed a simple looking request. The sales team wanted to collect data from customers about those customers’ hobbies. There was a predefined list, but the sales beasts wanted to be able to manage the list of hobbies themselves.
    It is what the customer asked for, dumb as it may be.

    +1

    I can imagine the lead-up to the implementation of that architecture:

    DBA: Here's an awesome many-to-many relationship setup for these tables. PHB: Why didn't you listen to us!?!??! We have a precise list of options that users can select! DBA: But this is more flexible, it will give you better data. PHB: We've had a focus group tell us what gives us better data! Implement this design right now! DBA: (dies a little inside with silent resignation)

  • m (unregistered)

    It's not THE Network, it's just Network.

    Glad I'm not the only one who noticed the coincidence of Luigi and a Martinet.

  • caper (unregistered)

    It's not one of those things that's really good or really bad, but it can be helpful.

    I gave up on that notion when I gave up programming in FORTRAN IV.

  • Anon (unregistered) in reply to Jeremy
    Jeremy:
    You'd swear some DBA/programmers think new tables/fields come out of their paycheck.

    Or maybe they thing the tables are wooden. Won't somebody think of the trees!

  • Jeff Grigg (unregistered) in reply to Jeremy
    Jeremy:
    You'd swear some DBA/programmers think new tables/fields come out of their paycheck.

    I find that The Real WTF is that no one has mentioned "Normalization" at any point in this comments. :-(

    "DBAs" who are anti-normalization? That's just wrong.

  • (cs) in reply to yojin

    The app I admin does that. In a couple places.

    I tried pointing out a few beginning dba efficiencies they could claim with a couple tiny changes, and got shut down.

    So I try very hard not to need those fields in reports. And drink.

  • Jeff Grigg (unregistered) in reply to Jeff Grigg

    Wikipedia URLs are considered SPAM on this site?!?!?

    How's that for a WTF?!?!?!?

  • (cs)
    “We hire only the smartest people we can, Luigi, but it doesn’t matter how smart people are if you don’t have control.”

    “I understand,” Luigi repeated.

    “Excellent. Then you understand why we can’t allow this database change to go through.”

    "Yes", Luigi admitted. "There's nothing wrong with the change itself, but you need to reject things on a regular basis to show everyone you're in control."

  • Dilligaf (unregistered) in reply to Jeff Grigg
    Jeff Grigg:
    Wikipedia URLs are considered SPAM on this site?!?!?

    How's that for a WTF?!?!?!?

    Like a Ninja in the night, Jeff Grigg noticed that whenever he tried to post Wikipedia URLs to his favourite website "Worse Than Fail", they were marked as SPAM by the redoubtable akismet engine (aka SKYNET).

    "This is why we can't have nice things in the comments" spat Gertrude, Jeff's dominatrix and bridge partner.

    Jeff felt his temper flare. "Fuck you akismet!!!" he cried. While Jeff knew The Book of Five Rings told him there would be hardshipss as he fought dragons, monsters, and Nagesh, this latest pain was just too much.

  • (cs) in reply to Dilligaf
    Dilligaf:
    Jeff Grigg:
    Wikipedia URLs are considered SPAM on this site?!?!?

    How's that for a WTF?!?!?!?

    Like a Ninja in the night, Jeff Grigg noticed that whenever he tried to post Wikipedia URLs to his favourite website "Worse Than Fail", they were marked as SPAM by the redoubtable akismet engine (aka SKYNET).

    "This is why we can't have nice things in the comments" spat Gertrude, Jeff's dominatrix and bridge partner.

    Jeff felt his temper flare. "Fuck you akismet!!!" he cried. While Jeff knew The Book of Five Rings told him there would be hardshipss as he fought dragons, monsters, and Nagesh , this latest pain was just too much.

    Why you calling my name?

  • (cs)

    Simple solution is to look no farther than bigdata. Hadoop is best for such kind of flowing text words like hobbies.

    Also bit based values are ok in C++ or C. In java it is simpler to go with Hibernate.

  • (cs)

    Fun fact: "akismet" is an acronym of "ska time."

  • (cs) in reply to Jeff Grigg
    Jeff Grigg:
    Jeremy:
    You'd swear some DBA/programmers think new tables/fields come out of their paycheck.

    I find that The Real WTF is that no one has mentioned "Normalization" at any point in this comments. :-(

    "DBAs" who are anti-normalization? That's just wrong.

    Any DBA who takes a side to the exlusion of of the other is wrong. Normalization is great for highly transactional systems, but not so great for reporting. Joins are rather expensive as an operation. Normalized schemas are going to require an awful lot of them. Typically for reporting you want to denormalize a good deal via your etl processes so the reports can have an easier time retrieving the data. Hence why data warehouses tend to shy away from normalized tables for the performance benefit of a star schema.

    Keep in mind a star schema would be a terrible choice for a transaction system. Buts its a great one for Analytical systems.

  • Jp (unregistered) in reply to ObiWayneKenobi

    You've never met SysAdmins, then, right?

    They can be just as paranoid and over-protective of their babies as DBAs. Moreso, sometimes, as the profession is a little older, so they've had more time to become entrenched.

    If you're irreplaceable, you're also un-promoteable.

  • Starbucks Lapdance (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    *The Network* is bleakly prescient.
    I'd be more concerned if Max Headroom becomes prescient. But it looks like Idiocracy is actually becoming the most prescient movie. But at least we won't have to learn how to use the three shells.

    It seems to me like it is a combination of both. Instead of goofy idiots at the top like Idicracy, we have mean idiots instead, like Max Headroom.

  • S (unregistered) in reply to Not a Frackin DBA
    Not a Frackin DBA:
    Well, I'm a developer -- have been for umpteen years. In my experience as a contractor in most of the places I;ve gone, the job "DBA" meant a person that can add/drop databases, set backup schedules, etc. The "database design" was done by developers. Developers also did the stored procs, views, etc.

    That's my experience too. A DBA is responsible for administering a database - working out how to configure the instance, how to lay stuff out on disk, all the stuff for getting optimal performance out of it. But they have little or no knowledge of what the data actually represents, so they have no business doing schema design or any of the other jobs that developers are responsible for...

  • S (unregistered) in reply to chubertdev
    chubertdev:
    Fun fact: "akismet" is an acronym of "ska time."

    Fun fact: the word you're looking for is "anagram".

  • Scoldog (unregistered) in reply to nonpartisan

    This is KAOS, Shtarker, not Chaos!

  • (cs) in reply to S
    S:
    chubertdev:
    Fun fact: "akismet" is an acronym of "ska time."

    Fun fact: the word you're looking for is "anagram".

    Fun fact: the word that that I was actually looking for was "caffeine"

  • (cs) in reply to S
    S:
    Not a Frackin DBA:
    Well, I'm a developer -- have been for umpteen years. In my experience as a contractor in most of the places I;ve gone, the job "DBA" meant a person that can add/drop databases, set backup schedules, etc. The "database design" was done by developers. Developers also did the stored procs, views, etc.

    That's my experience too. A DBA is responsible for administering a database - working out how to configure the instance, how to lay stuff out on disk, all the stuff for getting optimal performance out of it. But they have little or no knowledge of what the data actually represents, so they have no business doing schema design or any of the other jobs that developers are responsible for...

    It's funny how DBA is a well-known term, but DBD isn't.

  • Friedrice The Great (unregistered) in reply to Nagesh
    Nagesh:
    Dilligaf:
    Jeff Grigg:
    Wikipedia URLs are considered SPAM on this site?!?!?

    How's that for a WTF?!?!?!?

    Like a Ninja in the night, Jeff Grigg noticed that whenever he tried to post Wikipedia URLs to his favourite website "Worse Than Fail", they were marked as SPAM by the redoubtable akismet engine (aka SKYNET).

    "This is why we can't have nice things in the comments" spat Gertrude, Jeff's dominatrix and bridge partner.

    Jeff felt his temper flare. "Fuck you akismet!!!" he cried. While Jeff knew The Book of Five Rings told him there would be hardshipss as he fought dragons, monsters, and Nagesh , this latest pain was just too much.

    Why you calling my name?

    Cuz they need help with the database design you did for them.

  • QJo (unregistered) in reply to tragomaskhalos
    tragomaskhalos:
    One of the best-kept secrets in IT is that any moderately competent developer, armed with a few Oracle books (or SQLServer, or whatever) and a modicum of common sense, will run rings around 98% of self-styled "DBAs" out there.

    QFT. I bought my nephew a book on Oracle for his 13th birthday last week. He can already replace any DBA you're likely to meet. He ought to know, he's an expert, he told me himself.

  • QJo (unregistered) in reply to chubertdev
    chubertdev:
    S:
    Not a Frackin DBA:
    Well, I'm a developer -- have been for umpteen years. In my experience as a contractor in most of the places I;ve gone, the job "DBA" meant a person that can add/drop databases, set backup schedules, etc. The "database design" was done by developers. Developers also did the stored procs, views, etc.

    That's my experience too. A DBA is responsible for administering a database - working out how to configure the instance, how to lay stuff out on disk, all the stuff for getting optimal performance out of it. But they have little or no knowledge of what the data actually represents, so they have no business doing schema design or any of the other jobs that developers are responsible for...

    It's funny how DBA is a well-known term, but DBD isn't.

    DBD - isn't that Twiki's catchphrase?

  • Bl0wf1sh (unregistered)

    I think some people do not get what their final "solution" looks like...

    It is going to be

    tbl_hobbylist int_id hobby_name 1 fishing 2 photography 3 climbing

    tbl_customer int_id str_hobbyies 1 "1;2" 2 "2;3" 3 "1;2;3"

    I have seen it before. It is a way to design around many-to-many relationships without having to have a separate table. It is also really bad database design, and obviously will not have any relational integrity. On the other hand, it is usually no problem to split and parse the string, especially in web programming languages.

    Captcha: quis... Quis custodiet ipsos custodes?

Leave a comment on “Control”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article