• (cs) in reply to Grammar Nazi
    Grammar Nazi:
    That SQL expert's SQL was even worse than Alex Papadimoulis's english.

    FTFY

    /Style Nazi

  • Wyrd (unregistered) in reply to Dumb Rabbit
    Dumb Rabbit:
    wkk:
    Severity One:
    Fantastic!

    Now, for the next challenge, name the key between 'tab' and the left 'shift' key.

    I named mine George.

    George is my friend.

    But I want George to be my friend, too!

    Btw, kiddies on some ancient computers, there is not Caps Lock there, they have Meta instead.

    -- Furry cows moo and decompress.

  • dailyWTH (unregistered)

    Who cares about the 240 accounts? If they were too dumb to type in their e-Mail they wouldn't log in anyway. And the password or confirmation link the system should have sent didn't arive anyway...

  • justsomedude (unregistered) in reply to Duke of New York
    Duke of New York:
    justsomedude:
    Duke of New York:
    That's what you can expect when you hire any kind of technology "guru." A guru is a spiritually attuned Indian who lives in a remote shack. It has nothing to do with technology and anyone who tells you otherwise is going to scam you.

    I think your dictionary failed. words words words

    More like your point detection algorithm failed.

    I dunno about that, just ran it through QA and everything seems to be working properly.

    Even re-tried your note as a test case and yep, your claims still return false. Please submit a screenshot of the error or a set of steps to reproduce the problem, and we'll take another look.

  • anon (unregistered)

    "[email protected]" might be a perfectly valid email address (if there's an MX record for www.anyco.com).

    One of my pet peeves is when some lackwit implements a "validation" rule that rejects legitimate entries. Unless you know for sure that something is invalid (and can point to an RFC that supports your position) then you should accept what the user has supplied. Let the user fix it if it's wrong.

  • (cs) in reply to vr602
    vr602:
    Yeah well it's very easy to take the piss out of consultants and gurus when you see a story like this. I say, more fool them for 1) employing an arsehole, and for not spotting that he was an arsehole. It only takes 1 minute to find out if anyone is the expert they claim to be. 2) letting the guy work unsupervised - just ask what he's planning to do before he does it. 3) letting anyone loose on the live system without having tried it on a test/uat server first. 4) complaining about their situation when they brought items 1-3 on themselves. Yes the guy was a muppet, but he should be out of work, not working on your project. Your fault. You only found out that he couldn't string an SQL statement together *after* he'd destroyed your data? Nothing like bad luck, is there...
    In their defense: it was nine years ago -- circa 1999/2000. They were a small company -- an advertising company. From 1996 to 2000 I worked for a company that didn't have a Dev or QA environment or a QA team. Why? Because they weren't an IT company. They were a steel fabrication company that had a small IT department. They were concerned with matters relating to steel, not computers. Our department was a necessary evil, a red-headed stepchild. Management barely even tolerated our presence; they would hardly have kicked down the bucks for two (count 'em: two!) duplicates of our production system (Dev and QA).

    So we made do with what we had.

    Today, in my current position, we have dedicated Dev and QA environments for our SQL Servers. But I sometimes deal with other systems not directly under the control of our department, including an Oracle database for which there is no Dev, no QA version. Development is done directly against Production. Fortunately, it's all reporting, no updating. The username by which I connect has read-only access.

  • Comment (BBCode Okay) (unregistered) in reply to Dr. Evil

    That's no troll. That's the requirements process.

    I've done consulting, and without a stringent requirements document the client can keep on going "Oh one more thing..." Without any change in time/budget. It's all about pushback.

  • Ryan (unregistered)

    Using an email address as a primary key itself is an WTF.

    EmailAddress has an many-to-many relationship with Persons. So you should never use it as an key. One person can have many email addresses, and many people may use the same address.

    Sure, it's common to see the relationship forced into one-email-per-account on the web. However, you're still left with the fact that email addresses are changable. This happens even within an business. I'm sure you know of employees who've changed surnames.

    If you must use an email address as an login, then make it an secondary key (unique constraint, nonclustered).. Use an surrogate key for the relationships in the database. Then your users can get married/divorced without fear of messing your CMS up.

  • silent d (unregistered) in reply to Buddy

    Yeah, a safety setting like that would be so hard to bypass:

    UPDATE usr SET email = 'nonsense' WHERE 1=1;

    DELETE FROM usr WHERE 1=1;

  • (cs) in reply to Code Dependent
    Code Dependent:
    Today, in my current position, we have dedicated Dev and QA environments for our SQL Servers. But I sometimes deal with other systems not directly under the control of our department, including an Oracle database for which there is no Dev, no QA version. Development is done directly against Production. Fortunately, it's all reporting, no updating. The username by which I connect has read-only access.
    *Sniff* ... Ah, yes, it's all coming back to me now. The bats ... being called "Joe" for no obvious reason ... will somebody shut that goddamn dog up? Rip its testicles off, if necessary. You can always get a Filipina maid to use her teeth, so long as you pay for the dental bills in advance -- and I have a Gold Card, goddamnit.

    Ah, yes. "Fortunately, it's all reporting, no updating."

    Indeed. Precisely what sort of development environment might this be? And why would any company spend quadzillions on an Oracle installation, and then not hire or train an Oracle DBA? (This is not a theoretical question. A couple of jobs ago, I was tasked with porting a ~2K KLocs C++ Oracle system to SQL Server, just because the client didn't want to pay for an Oracle DBA; even part-time. Paying through their ass for the resultant nonsense was, however, apparently justifiable.)

    What you need, my man, is ... rummages through black bag ... ah, yes, I think I have it here -- NO! This is Essence Of Joe, abstracted directly from the adrenal gland! Poor Joe! I must honour his memory, or at least his glands, immediately ... gurk ... Eeek!

    Well, what I think you need is either VMWare or some other virtualisation system. I'm sure you think that too.

    I wonder if we can get your bosses to agree to this fairly obvious solution?

    Failing that, I've got various other glands from Joe that they might want to huff. Apparently he had an unexpressed anal gland. To paraphrase Dan "Potatoe" Quayle, an unexpressed anal gland is a terrible thing to waste.

  • Joshua (unregistered) in reply to Joe
    Other than the lack of a dev/backup system, the Guru holds the blame for this one. Like I said in a prior comment, I challenge any of you to create a system that uses a database backend and has no backup/dev that I couldn't completely ruin if given direct admin access to the production database.

    I roll out awk on Plan 9 for database.

  • hbin (unregistered) in reply to wkk
    Microsoft Access for simple internal applications and Perl/MySQL for client websites – probably weren’t the best fit
    Of course not. You should use perl and PostgreSQL...
  • Cujo (unregistered) in reply to Joe

    The other point was that that was only part of what this guy did. But allowing this fool access to a "production" database is sheer stupidity.

    I'm sure there's a whole bunch of log entries detailing just what else this nitwit did. I will note that the guy looks like he had no clue to syntax and probably kept referring to a book or something from the internet to keep refining the statements.

    But what was really bad was not trying to re-enable the constraints after each operation.

    It sure would have helped if they had backups too.

    I'm hoping there was a piece to the story where the supposed guru didn't get paid.

  • Severity Two (unregistered) in reply to Captain Oblivious
    Captain Oblivious:
    Severity One:
    Vechni:
    THE COMPANY IS PEPSI. GET IT? PEPSI CHALLENGE! I FINALLY FIGURED OUT ONE OF THESE. FUCK YES.
    Fantastic!

    Now, for the next challenge, name the key between 'tab' and the left 'shift' key.

    CONTROL, MOTHERFUCKER

    DO YOU SPEAK IT?

  • The Candidate of Change (unregistered)

    The SQL Guru must have been Barack Obama. CHANGE!

  • (cs) in reply to pink_fairy
    pink_fairy:
    Precisely what sort of development environment might this be? And why would any company spend quadzillions on an Oracle installation, and then not hire or train an Oracle DBA?
    It's your garden variety tale of disparate entities coming together to become one superentity, pink (Oh, by the way... which one's Pink?). We are a health care organization consisting of several hospitals, medical clinics and such. Although we build new hospitals from scratch, we also buy them, and when that happens they come to us bearing their godzillions of past and present medical records in the format and system that they have been using. This particular hospital brought the Oracle setup we're discussing. In the spirit of "bigger fish to fry" and "if it ain't broke, etc." no one in the manageriosphere has seen the need to revamp that system to the extent that you and I would. They do have a couple of... well, they're not called DBAs, they're called Admins, but their interaction with the database, so far as I can tell, is mostly limited to maintenance of the data. For anything extensive, like the recent port of an Informix database over to Oracle and a redesign of the schema, they bring in the third-party consultants who designed the system for them somewhere back in the mists of antiquity.
    pink_fairy:
    Well, what I think you need is either VMWare or some other virtualisation system. I'm sure you think that too.
    All of the developers on my team use VMs for our development. Our server team is in the ongoing process of virtualizing our servers (there are hundreds of them). But, for reasons I have not been told, that Oracle database seems to be outside of our jurisdiction. I wrote and maintain an application that accesses it, but it only organizes and displays data. The application for entering data was written by the third-party folks, and I have never seen it.
    pink_fairy:
    Failing that, I've got various other glands from Joe that they might want to huff. Apparently he had an unexpressed anal gland.
    Perhaps he would have enjoyed working with SQL Analyzer.
  • wtfer (unregistered)

    WTF was this person working on the production database anyway? WTF did they not review what he was doing? This company deserved to get burned.

  • lclark (unregistered) in reply to jaq

    Same here. I don't see what the Control key has to do with anything.

  • lclark (unregistered) in reply to lclark
    lclark:
    Same here. I don't see what the Control key has to do with anything.

    Silly me, making out of context comments.

  • Duke of New York (unregistered) in reply to justsomedude
    justsomedude:
    I dunno about that, just ran it through QA and everything seems to be working properly.

    Even re-tried your note as a test case and yep, your claims still return false. Please submit a screenshot of the error or a set of steps to reproduce the problem, and we'll take another look.

    Your point generation software is broken as well.

  • 50% Opacity (unregistered) in reply to Ryan
    Ryan:
    Using an email address as a primary key itself is an WTF.

    EmailAddress has an many-to-many relationship with Persons. So you should never use it as an key. One person can have many email addresses, and many people may use the same address.

    Sure, it's common to see the relationship forced into one-email-per-account on the web. However, you're still left with the fact that email addresses are changable. This happens even within an business. I'm sure you know of employees who've changed surnames.

    If you must use an email address as an login, then make it an secondary key (unique constraint, nonclustered).. Use an surrogate key for the relationships in the database. Then your users can get married/divorced without fear of messing your CMS up.

    One-one-thousand, two-one-thousand... Noooo, my grammar nazi is awaking! Make it stop, ｍａｋｅ　ｉｔ　ｓｔｏｐ！

  • hey persto! (unregistered)

    Tightly coupling a user account name with their email address is stupid to say the least.

    email addresses are not 1:1 with people, they can change and they can expire.

    Not having a separate username column was always going to cause problems.

    Also, abbreviated column names are horrible, unless you can find consistant rules for abbreviation - which you can't.

  • 50% Opacity (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    Either you're trolling, or you've never heard of ROLLBACK.

    I use MyISAM you insensitive clod.

  • Dontrell (unregistered)

    Stories like this never leave me satisfied. Did they call the "guru" out on his idiocy? What happened after this?

    I want more!

  • Anonymous Otaku (unregistered) in reply to Kermos
    Kermos:
    Those keyboards actually replace the space bar with special 'shift' keys that allow all Kana to be mapped onto the same keys as the roman alphabet. However, I'm not quite sure where space is on that layout... :)

    why would they need one? japanese doesn't have spaces

  • Anonymous Lexicographer (unregistered) in reply to Slicerwizard
    Slicerwizard:
    WTF does "feverously trying" mean?

    that you fail at dictionaries

  • (cs) in reply to Coolio
    Coolio:
    As in cruise control for cool?
    No, as in cruise control for COBOL.
  • Nathan (unregistered)

    Yeah, I still don't get why they didn't just abandon the consultant's changes and cut their losses.

  • jim steichen (unregistered) in reply to wkk
    wkk:
    Severity One:
    Vechni:
    THE COMPANY IS PEPSI. GET IT? PEPSI CHALLENGE! I FINALLY FIGURED OUT ONE OF THESE. FUCK YES.
    Fantastic!

    Now, for the next challenge, name the key between 'tab' and the left 'shift' key.

    I named mine George.

    I named mine Disabled for good.

  • (cs) in reply to Code Dependent
    Code Dependent:
    pink_fairy:
    ...why would any company spend quadzillions on an Oracle installation, and then not hire or train an Oracle DBA?
    This particular hospital brought the Oracle setup we're discussing. [...] They do have a couple of... well, they're not called DBAs, they're called Admins, but their interaction with the database, so far as I can tell, is mostly limited to maintenance of the data.

    So you have a several-years-old Oracle database... which almost certainly doesn't have ANY of the security patches of the last few years applied... and contains enough fresh, critical business data to sustain a reporting application. Nice. Where did you say you worked again? ;-)

  • (cs) in reply to Dave
    Dave:
    Why did the SQL 'guru' have access to their production database? I don't care how much of a 'guru' someone is, they shouldn't be diving into the production data without a way to undo what they did. The should have deleted the users with invalid emails.

    Because that is what he was hired to do? "Aderrific would bring on a SQL Guru to ... recover the countless invalid email addresses from the data."

    I can see it now "Hey guys I fixed all your bad emails in your test database. See ya."

    The data in production was bad, it needed to be fixed. How else would it be fixed?

  • (cs) in reply to hey persto!
    hey persto!:
    Tightly coupling a user account name with their email address is stupid to say the least.

    email addresses are not 1:1 with people, they can change and they can expire.

    Not having a separate username column was always going to cause problems.

    Also, abbreviated column names are horrible, unless you can find consistant rules for abbreviation - which you can't.

    Why is tightly coupling an email account with a user account a bad thing? Is the company going to give the same email out to multipe people? I know lets give the CEO the same email as the mail guy... I am guessing if the email account expires, the people will as well (at least as far as employment at the company goes)

    Someone said using the email as the primary key is bad. I agree but there was no evidence it was used as a primary key. It only said it was KEY information. I'm not sure how not having a separate username column was going to always cause problems. Users can still mistype their username too.

    In general I don't understand why email == username is a bad thing. If I want to create an account, and I don't want to share that account with someone then I don't use a shared email. Fairly simple, no?

  • 50% Opacity (unregistered) in reply to chrismcb
    chrismcb:
    Because that is what he was hired to do? "Aderrific would bring on a SQL Guru to ... recover the countless invalid email addresses from the data."

    I can see it now "Hey guys I fixed all your bad emails in your test database. See ya."

    The data in production was bad, it needed to be fixed. How else would it be fixed?

    Dump the data into a disposable test system, let the guru have at it, dump it back into production when and if you're satisfied with your gurus work?

    I wouldn't just give any random guru off the street direct access to the only copy of my valuable data. Heck, I don't even trust myself messing with production data. Guess that's just me though...

  • blivet (unregistered) in reply to chrismcb
    chrismcb:
    In general I don't understand why email == username is a bad thing. If I want to create an account, and I don't want to share that account with someone then I don't use a shared email. Fairly simple, no?

    You're assuming a level of technical sophistication and even interest in using the internet that just isn't there in many cases. I know several couples personally who share an email address, usually of the form [email protected], and I've run into this in my work too.

    These are just regular people, not very tech savvy, who use email and surf the web a little, and that's about it. I would be willing to bet that anyone who shares an email address has no interest in having another, and may not even know how to get one.

    I do consulting work for an organization whose database and membership website was set up up by a developer who thought using email addresses as usernames was the way to go. Now I get to deal with the fact that there are several members who are married and who share an email address with their spouse, who is also a member.

    They are paying good money to belong to this organization, and I don't think it's appropriate for the organization to dictate to them what email address they can use, especially when it's simple enough to ask them to create a unique username when they set up their account in the first place.

  • Jake Blues (unregistered) in reply to shadowman
    shadowman:
    Grammar Nazi:
    That SQL expert's SQL was even worse than Alex Papadimoulis's english.

    FTFY

    /Style Nazi

    I hate Illinois Style Nazis!
  • B1FF (unregistered) in reply to shadowman
    shadowman:
    50% Opacity:
    jaq:
    Severity One:
    Now, for the next challenge, name the key between 'tab' and the left 'shift' key.

    'Control'

    Japanese keyboard?

    No, my Japanese keyboard has 'Caps Rock.'

    YEAH YOU BET THEY DO THEY FUCKIN ROCK!!!!ONE!!

  • Keybounce (unregistered) in reply to anon
    anon:
    One of my pet peeves is when some lackwit implements a "validation" rule that rejects legitimate entries. Unless you know *for sure* that something is invalid (and can point to an RFC that supports your position) then you should accept what the user has supplied. Let the user fix it if it's wrong.
    You would be surprised at how many places assume that a domain name cannot end in a ".".

    So, if you throw "[email protected].", then it will be rejected.

    Sigh. Anyone remember sites like ".edu.com"? Or the DNS bugs that turned up when it was registered? Trailing dots are good things.

  • Daniel (unregistered)

    As a company, they got what they deserved. They took on a job which they were not qualified for and ended up with an unsatisfied customer.

    Now that's exactly what happened to the company they hired that SQL-Guru from...

    I like the irony in this!

  • (cs)

    The more I read about this, the more I'm NOT convinced that the SQL guru was really just stupid. The log of his activities clearly shows that this wasn't an act of random dumbness. The guy wilfully destroyed their database's integrity! So what if he did it on purpose? What if he worked for Coca-Cola?

  • (cs) in reply to silent d
    silent d:
    Yeah, a safety setting like that would be so hard to bypass:

    UPDATE usr SET email = 'nonsense' WHERE 1=1;

    DELETE FROM usr WHERE 1=1;

    Congratulations, you just found the entire f'ing point of the setting - that you have to bypass it intentionally.

  • Nico (unregistered) in reply to RBoy
    RBoy:
    Aww screw it, it must be the comment form's fault.

    FRITZ!!

  • praesent (unregistered) in reply to ML
    ML:
    Okay, let me see if I got this straight. Try to imagine this said with lots of melodrama as read by Don LaFontaine.

    IN A WORLD where two guys make a CRM system, they are HEROES. Just a couple of guys doing a bang up job. They didn't do anything wrong....

    UNTIL THE SQL GUY SHOWS UP. He makes a few updates to the database data. Most of those updates fail and don't do anything at all. He then disables a single CHECK constraint and updates a single field in the table on 240 rows.

    THEN SUDDENLY, the system our two heroes worked so slavishly on goes to shit. However, it is not the fault of the two guys who built a system so fragile that a single update to a non-critical field like E-MAIL could screw it so completely.

    Somehow, I think this story is a little embellished. If this one SQL update is what these two morons are trying to pin the failure on, they must really be desperate for a scapegoat for their WTF of a crappy, fragile system.

    did someone miss the bit were it said the email was also the login ID?

  • ExtraErrorMessage (unregistered) in reply to Vechni
    Vechni:
    Severity One:
    Vechni:
    THE COMPANY IS PEPSI. GET IT? PEPSI CHALLENGE! I FINALLY FIGURED OUT ONE OF THESE. FUCK YES.
    Fantastic!

    Now, for the next challenge, name the key between 'tab' and the left 'shift' key.

    CAPS LOCK. I WAS USING SHIFT THOUGH BECAUSE I DO NOT EVEN SEE THE POINT OF CAPS LOCK. MAYBE BECAUSE I HAVE PRETTY BIG HANDS AND I CAN EASILY REACH ANY KEY WHILE HOLDING MY PINKY ON SHIFT

    You press Shift with your dick? Now, that is really efficient. Will have to try, too. If only I was alone in the office.

  • Douglas (unregistered) in reply to anon
    anon:
    "[email protected]" might be a perfectly valid email address (if there's an MX record for www.anyco.com).
    It's also a perfectly valid email address if there is no MX record, but an A record.
  • (cs) in reply to Captain Oblivious
    Captain Oblivious:
    Severity One:
    Vechni:
    THE COMPANY IS PEPSI. GET IT? PEPSI CHALLENGE! I FINALLY FIGURED OUT ONE OF THESE. FUCK YES.
    Fantastic!

    Now, for the next challenge, name the key between 'tab' and the left 'shift' key.

    CONTROL, MOTHERFUCKER

    Naah, doesn't work, You need Ctrl+Alt+m/f.

  • Addison (unregistered) in reply to Ryan
    Ryan:
    Using an email address as a primary key itself is an WTF.

    EmailAddress has an many-to-many relationship with Persons. So you should never use it as an key. One person can have many email addresses, and many people may use the same address.

    Sure, it's common to see the relationship forced into one-email-per-account on the web. However, you're still left with the fact that email addresses are changable. This happens even within an business. I'm sure you know of employees who've changed surnames.

    If you must use an email address as an login, then make it an secondary key (unique constraint, nonclustered).. Use an surrogate key for the relationships in the database. Then your users can get married/divorced without fear of messing your CMS up.

    Reading comprehension. You need it.

    Where did it say they used it as a primary key? The article specifically said it was a field with a unique constraint. I also HIGHLY doubt that it was unchangeable once the account was created. Granted, it wasn't the best way to go about making accounts.

  • ClaudeSuck.de (unregistered) in reply to Ryan
    Ryan:
    Using an email address as a primary key itself is an WTF.

    EmailAddress has an many-to-many relationship with Persons. So you should never use it as an key. One person can have many email addresses, and many people may use the same address.

    Sure, it's common to see the relationship forced into one-email-per-account on the web. However, you're still left with the fact that email addresses are changable. This happens even within an business. I'm sure you know of employees who've changed surnames.

    If you must use an email address as an login, then make it an secondary key (unique constraint, nonclustered).. Use an surrogate key for the relationships in the database. Then your users can get married/divorced without fear of messing your CMS up.

    You shouldn't use an an in places where an an should actually be an a.

    Whereas using in in places where an in should be an i...

    Nothing is wrong in using an email address as UserID. If somebody likes to use [email protected], why not? You see people can have more than one passport (I have two valid ones from one country, don't ask how and why, just accept it) and more than one SSN. Or do you think that Yahoo, GMail, and all the others should rather use FirstName & " " & LastName as the PKey than the actual email address?

    CAPTCHA: nulla, that's what I thought, too.

  • ClaudeSuck.de (unregistered) in reply to pink_fairy
    pink_fairy:

    Paying through their ass for the resultant nonsense was, however, apparently justifiable.

    Ahm, I think that was actually YOUR fault.

  • resa (unregistered)

    No backup? WTF?

  • Joseph Le Brech (unregistered)

    Did you use stored procedures?

Leave a comment on “The SQL Guru”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article