• jaggerbush (unregistered)
    1. this+kills+my+soul+frist
  • My name (unregistered)

    id comment 6 'Frist"

  • Norman Diamond (unregistered)

    They need Control but they have Chaos.

  • (cs)

    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.

  • (cs)

    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.

  • 86 (unregistered)

    Control, Control, Control, and not a single employee named Max.

    Such a disappointment.

  • UnlimitedLTD (unregistered)

    Is it by mere coincidence that the image has a green theme, when the name of mr. protagonist is Luigi?

  • Ben (unregistered)

    Luigi's solution was mad. This should be a free-text field with a pre-defined list of common values.

  • tragomaskhalos (unregistered)

    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.

  • (cs) in reply to Ben
    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.

  • Sarah (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.

    Not quite.. Let me explain. It may look like a ManyToOne but that is only a mask to a hidden ManyToMany. Take the following:

    Customer:

    • Hobbby -> 7

    Hobby List:

    • Id -> 7
    • Value -> Fishing+Climbing+Whatever_else_hobby_is_here+rinse_and_repeat

    They basically put multiple values in 1 line in a ManyToOne relationship.

    The downside of course is that not only there will be a problem when there is a value with a + in it (small chance but still). But it is also hell for the code to maintain this list when the singular list of hobbies needs to update. You need to analyze the hobby table, split em all, check all combinations, update as needed, that code is hellish..

    TRWFT is simply that, cover a ManyToMany relationship as a ManyToOne to prevent some sort of foreign key and an extra table, which they regard as more control.. You can't call them exactly smart.. but this way no matter what with all the double checking you do have all the full control (and wtfyness) over the hobby table!

  • Meep (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.

    Bullshit, they'll make everything a string and ignore constraints entirely because it works better with their shitty ORM.

  • (cs) in reply to Sarah

    'snot what it says

  • Zacrath (unregistered) 
    int_id  str_hobbyies
1	fishing
2	photography
3	dancing + photography
4	climbing
5	climbing + fishing + photography
6       FileNotFound
  • Geoff (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.

    I think the wtf there is that they changed the field to a string type. Obviously there is at least a perceived need by Luigi to have more than one hobby associated with a customer. The DBA's schema does not allow this but by using a string instead Luigi's application can look up the hobby and append it. Basically they took a M:N relationship that needed to be M:M, and rather than implementing Luigi's correct solution they have instead decided to go with what will be a multivalued field.

  • David Banner (unregistered)

    TRWTF is - the plural of hobby is hobbies, not hobbyies.

    #pedantry

  • Refro (unregistered)

    int_id str_hobbyies

    1 fishing

    2 photography

    3 dancing + photography

    4 climbing

    5 climbing + fishing + photography

    6 FileNotFound

    7 Writing C++ code

  • (cs)

    Power sets to the rescue! Although I'm slightly disappointed that he didn't make a table with all permutations as well.

  • (cs)

    A free text field for the hobbies of a customer is probably the most accurate solution for even the most exotic diversions, but not really good if you need to find all customers that share a common hobby; because a clerk entering data might consider the suggested "photography" is not accurate enough and write e.g. "photo art" instead, so when searching for all customers interested in "photography" (e.g. to promote a new camera), this one isn't found.

  • (cs) in reply to Geoff

    Maybe if enough of you say it, then it will penetrate the alcohol.

    OK, yeah. He did say that.

    Sort of.

  • Black Bart (unregistered)

    Luigi should have implemented it as a foreign key bitfield

  • Le Forgeron (unregistered)

    Me think that the DBA is unable to come with a SQL statement to concat the hobbies of a join to return a single line per customer.

    Yet another DBA educated in Excel.

  • Geoff (unregistered) in reply to Meep
    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.

    Yes for smallish solutions this is true. If we are talking about some backwater eCommerce shop that measures annual revenues in millions you will come to this conclusion.

    Try taking the solution they implement and getting to scale to something an F2000 needs and you will be in a world of hurt. There are lots of bad DBA's out there but there are also lots of really good ones whose narrow focus allows them to spend develop a depth of knowledge that lets them really tease performance out of a database engine, some developer with an book open in his lap is never going to achieve.

    I once worked in shop where SOP was application developers write their own stored procedures their application needs and the the DBA rewrite them and hand them back. I was doing pretty esoteric stuff at the time so I never got to many changes sent back, but once and while I would get sent back some really clever ( but well commented ) PL/SQL sugar that really would run 10% faster in test. It was stuff I would not have come up with without eating, sleeping, and breathing PL/SQL for weeks.

  • belzebub (unregistered)

    Maybe I'm looking for a sense where there's none, but the hobby_ids table looks suspiciously like an "expanded bitfield" - if we accept that the table is anonymized and originally looked like this:

    1 	fishing
2 	photography
3 	fishing + photography
4 	climbing
5 	climbing + fishing + photography

    Then it looks like every single hobby has a "round" binary value:

    fishing:     0001
photography: 0010
climbing:    0100
... etc

    Then all combination makes perfect sense:

    fishing + photography = 0001 + 0010
climbing + fishing + photography = 0001 + 0010 + 0100
...

    Well.. SOME sense.. certainly not "DBA" sense..

  • Dev (unregistered) in reply to Meep

    I suppose you work with PHP "developers". He did say "moderately competent developer", see?

    "Everything a string" makes no sense with any typed language, and especially so with a ORM with validation turned on.

    Good DBA is a precious thing for developers too - devs should not know about the implementation issues with the DB, just understand the proper design patterns for the data & query language, and let the administrators work out the clustering, backups, fault tolerance.

    In this case the fault IS the DBA and the dev just needs to tolerate him until the contract finishes :)

  • EvilSnack (unregistered) in reply to belzebub
    belzebub:
    ... Then all combination makes perfect sense: 
    fishing + photography = 0001 + 0010
climbing + fishing + photography = 0001 + 0010 + 0100
...
    Well.. SOME sense.. certainly not "DBA" sense..
    I'm wondering how many different hobbies are supportable by this method. It's probably implementation-dependent.
  • (cs) in reply to ammoQ
    ammoQ:
    A free text field for the hobbies of a customer is probably the most accurate solution for even the most exotic diversions, but not really good if you need to find all customers that share a common hobby; because a clerk entering data might consider the suggested "photography" is not accurate enough and write e.g. "photo art" instead, so when searching for all customers interested in "photography" (e.g. to promote a new camera), this one isn't found.
    There is *no* ideal solution. Anything with preset values which are the only values supported causes problems when the data subjects have some interest outside the preset values, as well as problems with over-broadness of badly chosen categories(1). A free-text field can make it hard to search, as you say.(2) Preset values with a "pick exactly one" restriction are even worse - I'd have to choose one of my musical instruments,(3) XOR my interests in video games XOR my interest in odd corners of mediaeval English history(4) XOR ...

    Overall, "hobbies" are one of those things that has real potential for marketing purposes, but which computers are really bad at establishing usably AND accurately without human intervention.

    (1) Consider the hypothetical hobby-word "Music". What does this mean? Listening to music? Going to concerts? What sort of concerts? What genre(s) of music? Playing music? Which instrument(s)? etc.

    (2) You can mitigate the freeness of the field by providing suggestions from a pool of previous values that narrows as you type, as found on many search-related web sites (Goggle/Bong/etc., but also Wikipedia are good examples).

    (3) At least four, in my case, more if you consider acoustic and electric guitars to be sufficiently different.

    (4) The current project relates to what amounts to mythology rather than history, a bunch of stuff around the tale of Havelok.

  • Not a Frackin DBA (unregistered) in reply to Meep

    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.

    I have contracted at some very small places (< 30 employees in the company) and some very large places (> 14000 employees world-wide). In most cases I had the most trouble with DBAs not knowing what was going on when those DBAs were Microsoft Certified. Seems they spent too much time on studying the Microsoft answers for the test.

    Again, that's not saying ALL MS Certified -- or even ALL DBAs are the same. I have only worked at 10-12 companies as a contractor.

    Oracle DBAs, OTOH seem to always have it going on!

  • (cs) in reply to Norman Diamond
    Norman Diamond:
    They need Control but they have Chaos.
    Sorry about that, Chief.
  • ZoomST (unregistered) in reply to EvilSnack
    EvilSnack:
    belzebub:
    ... Then all combination makes perfect sense: 
    fishing + photography = 0001 + 0010
climbing + fishing + photography = 0001 + 0010 + 0100
...
    Well.. SOME sense.. certainly not "DBA" sense..
    I'm wondering how many different hobbies are supportable by this method. It's probably implementation-dependent.
    Well, if the integer is a 64-bit one, you have 64 different hobbies for ALL the users. That will run out of hobby types quickly as soon as sales people realizes that they need some more. I expect this DBA to add another int field, of course. That's "Control" in place of "Smartness".
  • Smug Unix User (unregistered)

    Just make a table function that loops the offending table and splits on the ' + ' and returns a proper result set. You're a smart person aren't you?

  • yojin (unregistered) in reply to belzebub

    I hate you for making me relive this.

    Worked on a system a few years ago where they eschewed a many to many relation ship with this technique. Except it was a string that looked like "YYYNNYNYYNNNYNYYYNYNYYNYYYYNNNNNNNNNNNN"

  • OneDayWhen (unregistered)

    "the new customer/hobby relationship to be a many-to-many relationship"

    Should be "many-to-many correspondence from customer to hobby". Specifically, 'correspondence' rather than 'relationship' and (see http://en.wikipedia.org/wiki/Correspondence_(mathematics) which has a direction. Avoid the term 'relationship' as regards relational technology: folks get start referring to the types involved in a 'relationship' as being 'relations', leading to further confusion that the relations in relational database theory are something to do with such 'relationships'.

  • anonymous (unregistered) in reply to belzebub
    belzebub:
    Maybe I'm looking for a sense where there's none, but the hobby_ids table looks suspiciously like an "expanded bitfield" - if we accept that the table is anonymized and originally looked like this: 
    1 	fishing
2 	photography
3 	fishing + photography
4 	climbing
5 	climbing + fishing + photography
    Then it looks like every single hobby has a "round" binary value: 
    fishing:     0001
photography: 0010
climbing:    0100
... etc
    Then all combination makes perfect sense: 
    fishing + photography = 0001 + 0010
climbing + fishing + photography = 0001 + 0010 + 0100
...
    Well.. SOME sense.. certainly not "DBA" sense..
    0001 + 0010 + 0100 is 7. 5 would be just climbing + fishing if it followed that schema.
  • Anon (unregistered)

    Stories like this is one of many reasons why I only lasted a short while in the corporate world; control and red-tape.

    The problem with so called "Clever" developers is that they come up with "clever" solutions that not only solve all current problems but all future imaginary problems too!

    However these "clever" solutions become a maintenance nightmare as no one can understand how it works and they eventually end up on this website.

    Whereas actual clever developers understand that the idea is to come up with simple, clear and concise solutions to the problem at hand and then refactor in the future when needed. Code that is clear and easy to understand is worth it weight in gold. (assuming code has mass and there is gravity...)

  • (cs) in reply to yojin
    yojin:
    Worked on a system a few years ago where they eschewed a many to many relation ship with this technique. Except it was a string that looked like "YYYNNYNYYNNNYNYYYNYNYYNYYYYNNNNNNNNNNNN"
    I think it's not as crazy as it looks. It's easier to read, write and retrieve than a bunch of id-to-id relations, and it's also pretty efficient. It's not easy to query, and certainly not efficiently, but that seems much less of a problem.
  • PB (unregistered)

    The thing with Database schemas, is that once you make a designchoice you're stuck with it.

    Every insert query would have been broken by the change to the schema.

    So, while it looks dirty, this is a workaround that at least doesn't break other stuff.

  • Krunt (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.

    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.

  • clive (unregistered) in reply to Krunt

    How does one tune a query if one doesn't know the finer points of a join statement?

    I've seen far too many really dumb things done by developers almost anywhere, so I know a DBA has to be involved in the design and architecture of the database side.

    (it's mostly scaling problems - people don't test on large enough data sets to discover how badly their SQL will perform when it hits our production DBs)

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)
    *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.
  • Wolfraider (unregistered)

    How much you want to bet it is a one-to-one now, Hobby ID is matched to customer ID. Basically they added a comment field to every record.

  • Letatio (unregistered)

    What kind of lousy DBA is this that he/she does not even know about the XML datatype? Amatuer.

  • golddog (unregistered)

    It's also just possible that Mr. Martinet was fed a line of bullshit and the DBA isn't really smart.

    Reminds me of the system our genius DBA set up. It associates stored procedures with an entity. Those procedures are then run to calculate data for that entity.

    The DBA set the whole system up to key off of the entity's name field instead of its unique id and made the argument that was "just a philosophical choice because either value could change."

    While I suppose it's technically true that the value in the column defined as an int identity could change, only one of those columns has an interface in the application to be administered.

    Surprisingly, it's not the unique id column. Of course, practically the first thing that happened is somebody changed the name of the entity and the calculations didn't update.

  • Mr Jinks (unregistered) in reply to David Banner
    David Banner:
    TRWTF is - the plural of hobby is hobbies, not hobbyies.

    #pedantry

    They tried calling the column str_hobby's but for some reason they started getting funny results from their queries..

  • (cs) in reply to Sarah
    Sarah:
    The downside of course is that not only there will be a problem when there is a value with a `+` in it (small chance but still).
    Hobby: C++ programming
  • CK (unregistered) in reply to Black Bart
    Black Bart:
    Luigi should have implemented it as a foreign key bitfield

    The application I maintain as part of a franchise does this for security roles.

    We currently have 30 roles on a 32 bit signed int. One of the remaining bits might cause holy havoc if used; the other is the sign bit.

  • Anon (unregistered)

    But what does the Book of Five Rings say about this database design?

  • (cs) in reply to Norman Diamond
    Norman Diamond:
    They need Control but they have Chaos.
    Another fine illustration of the wisdom in the sayings of the great philosopher Ly Tin Weedle: "Chaos is found in greatest abundance wherever order is being sought. It always defeats order, because it is better organized."
  • CK (unregistered) in reply to EvilSnack
    EvilSnack:
    belzebub:
    ... Then all combination makes perfect sense: 
    fishing + photography = 0001 + 0010
climbing + fishing + photography = 0001 + 0010 + 0100
...
    Well.. SOME sense.. certainly not "DBA" sense..
    I'm wondering how many different hobbies are supportable by this method. It's probably implementation-dependent.

    I wonder how long it would take for someone to hard code a hobby combination into the application with this method.

  • (cs) in reply to UnlimitedLTD
    UnlimitedLTD:
    Is it by mere coincidence that the image has a green theme, when the name of mr. protagonist is Luigi?
    And the other guy is Mr Martinet.

Leave a comment on “Control”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article