Stored Procedures, The Porn Guy, and Non-returnable Email

« Return to Article
  • dpm 2011-01-27 09:04
    I fell into it right out of high school and made enough money to pay for university
    I had no idea that being a pr0n photographer paid so well! Why didn't anyone tell me?
  • minkey 2011-01-27 09:12
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
  • minkey 2011-01-27 09:12
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
  • Paco 2011-01-27 09:14
    It's sad that people are such prudes. If it were me interviewing that guy would have moved to the top of the list.
  • backForMore 2011-01-27 09:15
    Don't bother posting without a non-returnable photograph.
  • pjt33 2011-01-27 09:18
    backForMore:
    Don't bother posting without a non-returnable photograph.

    Does it have to be a photograph of me?
  • Nagesh Kukunoor 2011-01-27 09:19
    Store procedure was an honest mistake.


    CAPTCHA: LUPTATUM

  • TheMugs 2011-01-27 09:19
    We try to keep secret. Now that the news is out, I guess a lot of people will come into the profession and it will bring our salary down.
  • Porn Gal 2011-01-27 09:20
    The real WTF is that the 'Porn Guy' is called Liz.
  • Melnorme 2011-01-27 09:23
    I bet the Porn Guy had plenty of non-returnable photographs for the third company
  • TheSHEEEP 2011-01-27 09:24
    Porn Gal:
    The real WTF is that the 'Porn Guy' is called Liz.


    CAPTCHA: secundum .... indeed.
  • dpm 2011-01-27 09:24
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.
  • TPG 2011-01-27 09:25
    pjt33:
    backForMore:
    Don't bother posting without a non-returnable photograph.

    Does it have to be a photograph of me?


    I've got some very tasteful pictures of my girlfriend I took just out of high-school. Would one of those work?
  • dolor 2011-01-27 09:29
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?
  • too_many_usernames 2011-01-27 09:33
    This is a story that is so unbelievable I wouldn't believe it if I hadn't experienced it personally.

    We occasionally give a simple coding test to candidates. We are a primarily embedded systems company, so one question on the test is:

    "What is an atomic operation?"

    We have in our archives the hand-written response: "it involves the nucleus of atoms."
  • luis.espinal 2011-01-27 09:34
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question. After all, it was an interview for a database developer position, and it would have been reasonable to ask for one's experience with stored procedures. Where they simple? Where they complex? Any problems in deployment? How do you debug them? Pros, cons? The whole enchilada. I don't see how this question was teh failx0r.
  • Julchen 2011-01-27 09:34
    "everyone is not technically inclined"

    I'm not sure if that is what you really meant ;)

    capio: leo?
  • Nagesh Kukunoor 2011-01-27 09:37
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis
  • OldPeter 2011-01-27 09:39
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.
  • Adriano 2011-01-27 09:39
    luis.espinal:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".
  • anon 2011-01-27 09:43
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.


    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.
  • dolor 2011-01-27 09:48
    Adriano:
    luis.espinal:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".

    Because it's merely the question: "Are you familiar with stored procedures?" slightly rephrased.

    Picture this: you're in an interview. The candidate asks you: "Do you know x?" You want to appear qualified for the job. What is your answer: yes or no?
  • Chris 2011-01-27 09:49
    Adriano:
    luis.espinal:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".

    The question's a bit open-ended as it stands though. It might be more time-effective to ask "How much, if at all, have you used them?" followed up by things like "What are the benefits of using them?" and a few lower-level questions.
  • dpm 2011-01-27 09:51
    OldPeter:
    This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion
    I didn't see that at all. The point of the story was that the company warned prospective hires that photographs emailed to them would not be returned.
  • jger 2011-01-27 09:52
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany.


    It´s not about sending a non-returnable photograph at all but about sending a non-returnable photograph by email.
  • luis.espinal 2011-01-27 09:53
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis


    Don't fall for that kool-aid. ORMs have their place, but are not general silver bullets. Nothing is. Like anything, they have limitations (severe limitations), and if your architecture deeply relies on having a ORM, you might as well model and store your data on a OO or graph database instead of plastering yet another layer of abstraction on top of your persistence layer just so that you can claim "look, OO!".

    Stored procedures have their place, and like anything (ORMs included), they can be used wisely or abused. After all, there are massive relational systems that work just fine and that need extension or integration. And there are applications that are naturally relational (and for which using a ORM is like forcing a square peg on a round hole.

    What are you going to do? Rewrite them all just so that they use a ORM? Dead to stored procedures, nice wishful (and impractical from an engineering standpoint) thinking. When people start saying "death to this or that", it indicates they might not have a firm grasp on the technical issues at hand.
  • j 2011-01-27 09:55
    non-returnable email...

  • Ken B. 2011-01-27 09:58
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.
    I think it's one of those "gray areas", depending on the job. For example, how does that person's former job affect the public's perception of the company? (And public perception can affect the ability of a person to do their job if the job involves a lot of interaction with "the public".)
  • Henning Makholm 2011-01-27 09:58
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
  • <> 2011-01-27 10:01
    jger:
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany.


    It´s not about sending a non-returnable photograph at all but about sending a non-returnable photograph by email.

    Your from Germany? Good, I have a question about my German automobile. I drive a Prius, and I heard that diesels get better gas mileage. So I filled it with diesel and now it's making funny noises. Can you help?
  • luis.espinal 2011-01-27 10:02
    dolor:
    Adriano:
    luis.espinal:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".

    Because it's merely the question: "Are you familiar with stored procedures?" slightly rephrased.

    Picture this: you're in an interview. The candidate asks you: "Do you know x?" You want to appear qualified for the job. What is your answer: yes or no?


    In the affirmative, it would be "yes, I've done such and such with x", or "yes, but my experience with x have been limited to such and such".

    In the negative, it would be "no, but I've worked on things that resemble x in such and such way", or "no, I've only read about them", or "no, I'm not familiar with that technology."

    Moreover, every time I get a question, I repeat the question back to the interviewer (and rephrase and reformulate if the question is too open ended), to make sure it is what he/she is asking.

    In an interview, no question is truly a yes/no question, regardless of how the question is presented. If you treat the question as a yes/no question (and the interviewer might be tricking you into doing so for whatever reason), that's on you.

    Besides, in an interview for a database development position, how else can someone applying for that position can take "Do you know x"? Context is everything, and the person going into an interview is responsible for being aware of that technology-specific context. Interviewers are not obliged to chew and ruminate questions out until they are these 100% unambiguous, easily digestible snow flakes. They are not.

    Maybe (and I'm honestly saying this) I'm missing something legit that you are trying to say with regard to the validity of the interview question. But honestly, I just don't see it.
  • dolor 2011-01-27 10:03
    Chris:
    Adriano:
    luis.espinal:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".

    The question's a bit open-ended as it stands though. It might be more time-effective to ask "How much, if at all, have you used them?" followed up by things like "What are the benefits of using them?" and a few lower-level questions.

    Your the reason why I have to work with incompitant numbskulls. Try boning up on your interview skills.
  • amischiefr 2011-01-27 10:05
    dpm:
    I fell into it right out of high school and made enough money to pay for university
    I had no idea that being a pr0n photographer paid so well! Why didn't anyone tell me?

    I don't think he was the 'photographer', if you know what I mean. Either that or he got his degree from ITT Tech...
  • Ken B. 2011-01-27 10:05
    Ken B.:
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.
    I think it's one of those "gray areas", depending on the job. For example, how does that person's former job affect the public's perception of the company? (And public perception can affect the ability of a person to do their job if the job involves a lot of interaction with "the public".)
    And, as someone else pointed out, "former job" is probably not on the list of things you can't "discriminate" against.

    I know, for example, that a landlord can refuse to rent to someone based on their job. (At least that's true in New York.)
  • too_many_usernames 2011-01-27 10:06
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?

    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!
  • amischiefr 2011-01-27 10:08
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?

    Actually these are the kinds of questions that work best. You get the person talking about a subject and let them either talk themselves into or out of a job. They will either know the subject and elaborate on it, or they will try to BS you and you'll pick up on that too.

    What kind of questions would you propose?
  • luis.espinal 2011-01-27 10:10
    Chris:
    Adriano:
    luis.espinal:

    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".

    The question's a bit open-ended as it stands though. It might be more time-effective to ask "How much, if at all, have you used them?" followed up by things like "What are the benefits of using them?" and a few lower-level questions.


    Interviews are supposed to contain open-ended questions. It is up the interviewee to negotiate and work with the interviewer for an interpretation of such questions. If the interviewee just takes the question 'as-is', that's his/her fail. The interviewer gets a lot of feedback by looking at how the interviewee reacts to such questions - is he/she engaging me in refining the question until it becomes unambiguous, asking for clarifications? Or is he/she acting like a dumb oracle automaton?
  • Kempeth 2011-01-27 10:10
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?

    Iron atoms are often embedded into a patient's body during operations...


    Also I am surprised that the person in the last story was to cheap to visit his friendly file manager and spring for another copy of his jpeg...
  • Ken B. 2011-01-27 10:12
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"
    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!
    But atoms can be broken down into smaller components, making the term a misnomer. Perhaps we should start using "quarkic operation"[tm] instead?
  • luis.espinal 2011-01-27 10:13
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?

    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!


    To be fair, atomic operations are not just restricted to that realm. They are at the heart of database transactions (or in systems programing wrt to uninterruptible ops). A person with a CS degree should (must) know what an atomic operation is, at least conceptually.
  • Nagesh Kukunoor 2011-01-27 10:29
    luis.espinal:
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis


    Don't fall for that kool-aid. ORMs have their place, but are not general silver bullets. Nothing is. Like anything, they have limitations (severe limitations), and if your architecture deeply relies on having a ORM, you might as well model and store your data on a OO or graph database instead of plastering yet another layer of abstraction on top of your persistence layer just so that you can claim "look, OO!".

    Stored procedures have their place, and like anything (ORMs included), they can be used wisely or abused. After all, there are massive relational systems that work just fine and that need extension or integration. And there are applications that are naturally relational (and for which using a ORM is like forcing a square peg on a round hole.

    What are you going to do? Rewrite them all just so that they use a ORM? Dead to stored procedures, nice wishful (and impractical from an engineering standpoint) thinking. When people start saying "death to this or that", it indicates they might not have a firm grasp on the technical issues at hand.


    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.


    Captcha: praesent (I am present)
  • hoodaticus 2011-01-27 10:29
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    Presumably, they have long-running simultaneous processes sharing state. Such as communications and storage providers and their clients.
  • Safely anonymous 2011-01-27 10:32
    anon:

    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.


    And of course, the onus is on *you* to prove that you weren't hired because of one of the "naughty" categories. As long as they can come up with a reasonable explanation, they're off the hook. (And even if you win, I wouldn't count on a long and productive stay there anyway.)
  • hoodaticus 2011-01-27 10:36
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
    If you have ever written a stored procedure in your life, you would not forget what they are.
  • Some Wonk 2011-01-27 10:38
    Ken B.:
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"
    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!
    But atoms can be broken down into smaller components, making the term a misnomer. Perhaps we should start using "quarkic operation"[tm] instead?

    It's atoms all the way down!
  • dpm 2011-01-27 10:39
    amischiefr:
    dpm:
    I had no idea that being a pr0n photographer paid so well! Why didn't anyone tell me?

    I don't think he was the 'photographer', if you know what I mean. Either that or he got his degree from ITT Tech...
    In the first place,
    “I used to be a photographer in the adult film industry,” I told them.
    Seems fairly certain --- especially when you consider that admitting to TDWTF that you were a *performer* would make the story better, not worse.

    In the second, "Liz" is usually a she, not a he.
  • Matthew 2011-01-27 10:41
    Ken B.:
    I think it's one of those "gray areas", depending on the job. For example, how does that person's former job affect the public's perception of the company? (And public perception can affect the ability of a person to do their job if the job involves a lot of interaction with "the public".)

    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    (What's with the black-on-dark-grey captcha? Discriminating against people with poor night sight?)
  • Delicious pie is delicious. 2011-01-27 10:43
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Yeah, it really is a bit like asking an imperative programmer, "so, how about those user-defined functions?" Or like asking a truck driver, "so how do you feel about steering wheels?"
  • Nagesh Kukunoor 2011-01-27 10:45
    dolor:
    Chris:
    Adriano:
    luis.espinal:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Me no get it. Why is it an interview fail? Honest question.

    Indeed. If the candidate has only worked with MySQL, which is sad but common, the answers can be "none", "just starting to use them", and "I have used them since they appeared in 5.1 two years ago".

    The question's a bit open-ended as it stands though. It might be more time-effective to ask "How much, if at all, have you used them?" followed up by things like "What are the benefits of using them?" and a few lower-level questions.

    Your the reason why I have to work with incompitantnumbskulls. Try boning up on your interview skills.


    Brush up your spelling skills.

  • Delicious pie is delicious. 2011-01-27 10:46
    hoodaticus:
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
    If you have ever written a stored procedure in your life, you would not forget what they are.


    No, if you had never actually learned SQL and, like most of the people I see on DB forums, just copy-paste code you might not actually know what a stored procedure is, even if you did use them.
  • boog 2011-01-27 10:49
    What's so funny? Shouldn't database developers be familiar with store procedure?

    Or are you fine with them taking the forklift for a joyride every Friday afternoon?
  • stibbons 2011-01-27 10:49
    together with a non-returnable photograph to careers@-------.com


    So what happens if your email bounces?
  • Nagesh Kukunoor 2011-01-27 10:50
    hoodaticus:
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
    If you have ever written a stored procedure in your life, you would not forget what they are.


    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.
  • TW 2011-01-27 10:59
    hoodaticus:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    Presumably, they have long-running simultaneous processes sharing state. Such as communications and storage providers and their clients.


    Are you sure it doesn't have something to do with the absence of a file system? Seems to me there was a discussion on here about that not too long ago....
  • Porn Geezer 2011-01-27 11:01
    Nagesh Kukunoor:
    hoodaticus:
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
    If you have ever written a stored procedure in your life, you would not forget what they are.


    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.


    maybe for you, ducky.
  • luis.espinal 2011-01-27 11:01
    Nagesh Kukunoor:
    luis.espinal:
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis


    Don't fall for that kool-aid. ORMs have their place, but are not general silver bullets. Nothing is. Like anything, they have limitations (severe limitations), and if your architecture deeply relies on having a ORM, you might as well model and store your data on a OO or graph database instead of plastering yet another layer of abstraction on top of your persistence layer just so that you can claim "look, OO!".

    Stored procedures have their place, and like anything (ORMs included), they can be used wisely or abused. After all, there are massive relational systems that work just fine and that need extension or integration. And there are applications that are naturally relational (and for which using a ORM is like forcing a square peg on a round hole.

    What are you going to do? Rewrite them all just so that they use a ORM? Dead to stored procedures, nice wishful (and impractical from an engineering standpoint) thinking. When people start saying "death to this or that", it indicates they might not have a firm grasp on the technical issues at hand.


    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.


    Captcha: praesent (I am present)


    So? Do you actually have to consult with the VP (as opposed to technically evaluate my statements own your own)? I'm amused, but not that much surprised. Tell your VP I'm mildly honored that he thinks I'm partially right. I guess since he's a VP of tech dev his opinion should count for something on these internet forums realms :P

    -- and by the way --

    I've been working with ORMs and SQL-mappers for a while now (a long while). Hibernate, iBatis, in-house developed, you name it. I know for experience what you can and cannot do. I still have to see an application with high volume of RDMB traffic being able to use a ORM without having to add extra layers of L1/L2 application caching, making the whole thing a big, fat lasagna architecture.

    Complexity for the sake of just using yet a new flashing toy is not engineering.
  • Clumsy Kid 2011-01-27 11:03
    And if you live in the United States, then you would be wrong. There are only a few set things that are protected, such as Age and Gender. Otherwise you can discriminate on just about anything.
  • goob 2011-01-27 11:13
    Ok. Let's review:

    1) Liz gets job and goes to college.
    2) Liz interviews for new job, putting past job on resume.
    3) Company blacklists Liz based purely on the answer to a seemingly-benign interview question.
    4) Liz gets a new job.
    5) Liz interviews candidate.
    6) Liz blacklists candidate based purely on the answer to a seemingly-benign interview question.
  • The Flaming Foobar 2011-01-27 11:15
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly.


    My thoughts exactly. A job interview can be very nervewracking, and mistakes like that are easy to make if you are the type of person who tends to get nervous in those situations.
  • grits 2011-01-27 11:15
    Clumsy Kid:
    And if you live in the United States, then you would be wrong. There are only a few set things that are protected, such as Age and Gender. Otherwise you can discriminate on just about anything.

    That's why I'll only live in Mexico
  • The Corrector 2011-01-27 11:16
    goob:
    Ok. Let's review:

    1) Liz gets job and goes to college.
    2) Liz interviews for new job, putting past job on resume.
    3) Company blacklists Liz based purely on the answer to a seemingly-benign interview question.
    3.1) Company adds insult to injury by calling her a guy.
    4) Liz gets a new job.
    5) Liz interviews candidate.
    6) Liz blacklists candidate based purely on the answer to a seemingly-benign interview question.

    FTFY
  • Nagesh Kukunoor 2011-01-27 11:20
    luis.espinal:
    Nagesh Kukunoor:
    luis.espinal:
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis


    Don't fall for that kool-aid. ORMs have their place, but are not general silver bullets. Nothing is. Like anything, they have limitations (severe limitations), and if your architecture deeply relies on having a ORM, you might as well model and store your data on a OO or graph database instead of plastering yet another layer of abstraction on top of your persistence layer just so that you can claim "look, OO!".

    Stored procedures have their place, and like anything (ORMs included), they can be used wisely or abused. After all, there are massive relational systems that work just fine and that need extension or integration. And there are applications that are naturally relational (and for which using a ORM is like forcing a square peg on a round hole.

    What are you going to do? Rewrite them all just so that they use a ORM? Dead to stored procedures, nice wishful (and impractical from an engineering standpoint) thinking. When people start saying "death to this or that", it indicates they might not have a firm grasp on the technical issues at hand.


    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.


    Captcha: praesent (I am present)


    So? Do you actually have to consult with the VP (as opposed to technically evaluate my statements own your own)? I'm amused, but not that much surprised. Tell your VP I'm mildly honored that he thinks I'm partially right. I guess since he's a VP of tech dev his opinion should count for something on these internet forums realms :P

    -- and by the way --

    I've been working with ORMs and SQL-mappers for a while now (a long while). Hibernate, iBatis, in-house developed, you name it. I know for experience what you can and cannot do. I still have to see an application with high volume of RDMB traffic being able to use a ORM without having to add extra layers of L1/L2 application caching, making the whole thing a big, fat lasagna architecture.

    Complexity for the sake of just using yet a new flashing toy is not engineering.


    I met him on a coffee break. We have coffee breaks four times a day. We don't actually drink coffee, since the canteen boy doesn't always deliver coffee on time. We talk about IT trends.
  • tehR 2011-01-27 11:21
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?

    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!


    Data incoherency is never your friend - in real-time systems or otherwise.
  • The Flaming Foobar 2011-01-27 11:22
    Chris:
    "What are the benefits of using them?" and a few lower-level questions.


    Wow, that's a can of worms, right there. I wouldn't get the job after that question, for sure.

    Captcha: damnum - indeed!
  • trwtf 2011-01-27 11:24
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.


    Some HR departments here require that an assistant review any resumes that come in and remove potential discrimination issues - photographs and dates on degrees, mostly- before anyone actually evaluates them. Typically, membership in something like the AARP or NAACP would be removed, since it's not relevant, but something like an officer position in one of those groups or membership in a professional organization (which might include "Gay Firefighters of America" or something) would be left, since they would be career-related.

    This makes sense to me, even if you remove the lawsuit issue. Why do you want to clutter up your resume with irrelevancies like a photograph?
  • boog 2011-01-27 11:27
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.
    My experience tells me you're bonkers. Funny how something like experience varies from person to person.

    Nagesh Kukunoor:
    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.
    Amateur. You have to establish your senior VP as a respected authority figure before employing that fallacy; none of us even know who he is yet.

    Nagesh Kukunoor:
    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.
    Well, I'm not an "old FUDDY DUDDY" and I write stored procedures. I guess I just proved you wrong. Generalizations suck, don't they?
  • The Flaming Foobar 2011-01-27 11:30
    amischiefr:

    Actually these are the kinds of questions that work best. You get the person talking about a subject and let them either talk themselves into or out of a job.


    They work great if you are looking for a lecturer.

    If you are looking for a person capable of writing high-quality code, you should probably try to find out what kind of problem-solving skills they have and not what they have memorized from DB101.

    There is practically no difference between writing, say, a Perl script, and a stored procedure. Any experienced programmer will need one good example of a stored procedure, and maybe a list of dos and dont's, and they'll be writing there own in like 5 minutes.
  • q3 2011-01-27 11:33
    Discrimination for the 2nd Liz may be totally valid. In some countries, this practice is illegal, and if this company was based in one of those countries or had customers there; hiring Liz would jeopardize that relationship and possibly her personal safety.
  • frits 2011-01-27 11:34
    TW:
    hoodaticus:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    Presumably, they have long-running simultaneous processes sharing state. Such as communications and storage providers and their clients.


    Are you sure it doesn't have something to do with the absence of a file system? Seems to me there was a discussion on here about that not too long ago....


    It's how they store porn photos in C data structs, I do believe.
  • frits 2011-01-27 11:35
    Discrimination because someone is a former porn photographer? Lame.

    It's not like they used to be a lawyer or something.
  • boog 2011-01-27 11:35
    frits:
    TW:
    hoodaticus:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    Presumably, they have long-running simultaneous processes sharing state. Such as communications and storage providers and their clients.


    Are you sure it doesn't have something to do with the absence of a file system? Seems to me there was a discussion on here about that not too long ago....


    It's how they store porn photos in C data structs, I do believe.
    Non-returnable porn photos, you mean.
  • shadowman 2011-01-27 11:36
    boog:
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.
    My experience tells me you're bonkers. Funny how something like experience varies from person to person.

    Nagesh Kukunoor:
    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.
    Amateur. You have to establish your senior VP as a respected authority figure before employing that fallacy; none of us even know who he is yet.

    Nagesh Kukunoor:
    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.
    Well, I'm not an "old FUDDY DUDDY" and I write stored procedures. I guess I just proved you wrong. Generalizations suck, don't they?


    Hey man, I was writing stored procedures before stored procedures were cool!
  • Leader of the Troll Army 2011-01-27 11:36
    The Flaming Foobar:
    amischiefr:

    Actually these are the kinds of questions that work best. You get the person talking about a subject and let them either talk themselves into or out of a job.


    They work great if you are looking for a lecturer.

    If you are looking for a person capable of writing high-quality code, you should probably try to find out what kind of problem-solving skills they have and not what they have memorized from DB101.

    There is practically no difference between writing, say, a Perl script, and a stored procedure. Any experienced programmer will need one good example of a stored procedure, and maybe a list of dos and dont's, and they'll be writing there own in like 5 minutes.

    Please cease all mispellings of words in your troll posts, as this immediately identifies you as a troll and makes the whole endeavor pointless.
  • airdrik 2011-01-27 11:41
    shadowman:
    boog:
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.
    My experience tells me you're bonkers. Funny how something like experience varies from person to person.

    Nagesh Kukunoor:
    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.
    Amateur. You have to establish your senior VP as a respected authority figure before employing that fallacy; none of us even know who he is yet.

    Nagesh Kukunoor:
    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.
    Well, I'm not an "old FUDDY DUDDY" and I write stored procedures. I guess I just proved you wrong. Generalizations suck, don't they?


    Hey man, I was writing stored procedures before stored procedures were cool!


    Looks like the troll is winning
  • Abso 2011-01-27 11:47
    Leader of the Troll Army:

    Please cease all mispellings of words in your troll posts, as this immediately identifies you as a troll and makes the whole endeavor pointless.

    Members of armies are supposed to be identifiable, that's why they wear uniforms.

    If you were Leader of the Troll Intelligence Service, then you'd have a point.
  • trwtf 2011-01-27 11:49
    The Flaming Foobar:
    amischiefr:

    Actually these are the kinds of questions that work best. You get the person talking about a subject and let them either talk themselves into or out of a job.


    They work great if you are looking for a lecturer.

    If you are looking for a person capable of writing high-quality code, you should probably try to find out what kind of problem-solving skills they have and not what they have memorized from DB101.


    If someone's reciting stuff they memorized in class, that would count as "talking themself out of a job". If you can't speak coherently about a topic for a minute or two, it's pretty clear you don't understand it. It might be different if you're interviewing with Nicholas Parsons, but that's kettle of fish of a different color.
  • Tim G 2011-01-27 11:52
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?
  • Stephen Cleary 2011-01-27 11:54
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?


    Embedded systems sometimes do not have higher-level concurrency structures available. In this case, atomic operations are commonly used to build them. At its core, a mutex/semaphore/etc. is a lock-free structure built on atomic ops.

    In my day job, we do have higher-level concurrency structures, but running on a platform without any useful atomic operations (i.e., only read/write are atomic; there's nothing that can make decisions like compare-and-exchange).
  • drusi 2011-01-27 11:58
    Ken B.:
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"
    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!
    But atoms can be broken down into smaller components, making the term a misnomer. Perhaps we should start using "quarkic operation"[tm] instead?

    The word is derived from the Greek átomos, meaning "unable to be cut." So it's a perfectly good word for atomic operations. It's just not appropriate for actual atoms.
  • anon 2011-01-27 12:10
    dolor:

    Your the reason why I have to work with incompitant numbskulls. Try boning up on you're interview skills.


    FTFY

    :b

    incassum I'm wrongum, pleaseum ignore-em
  • trwtf 2011-01-27 12:12
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?


    Because the question wasn't "what was the most interesting job you've ever had", it was "what is the most interesting thing you've ever worked on". I think your phrase - "not remotely relevant" is the right one.

    The fail wasn't necessarily in mentioning the job, it was in misunderstanding the question.
  • Lockwood 2011-01-27 12:17
    TW:
    Are you sure it doesn't have something to do with the absence of a file system? Seems to me there was a discussion on here about that not too long ago....


    My photo is attached to the application, and I understand it is non-returnable:
    True
    False
    File not Found
  • Tim G 2011-01-27 12:32
    trwtf:
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?

    Because the question wasn't "what was the most interesting job you've ever had", it was "what is the most interesting thing you've ever worked on". I think your phrase - "not remotely relevant" is the right one.

    I don't disagree with you, but that's not what Matthew seems to be saying, which is that the fact that talking about one's work in the adult film industry isn't appropriate in some kind of inherent sense. Which is bullshit.
  • Jaime 2011-01-27 12:35
    luis.espinal:
    Nagesh Kukunoor:
    luis.espinal:
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis


    Don't fall for that kool-aid. ORMs have their place, but are not general silver bullets. Nothing is. Like anything, they have limitations (severe limitations), and if your architecture deeply relies on having a ORM, you might as well model and store your data on a OO or graph database instead of plastering yet another layer of abstraction on top of your persistence layer just so that you can claim "look, OO!".

    Stored procedures have their place, and like anything (ORMs included), they can be used wisely or abused. After all, there are massive relational systems that work just fine and that need extension or integration. And there are applications that are naturally relational (and for which using a ORM is like forcing a square peg on a round hole.

    What are you going to do? Rewrite them all just so that they use a ORM? Dead to stored procedures, nice wishful (and impractical from an engineering standpoint) thinking. When people start saying "death to this or that", it indicates they might not have a firm grasp on the technical issues at hand.


    I just spoke to the senior vice-president of technical development in my company and he thinks you're only partly right.


    Captcha: praesent (I am present)


    So? Do you actually have to consult with the VP (as opposed to technically evaluate my statements own your own)? I'm amused, but not that much surprised. Tell your VP I'm mildly honored that he thinks I'm partially right. I guess since he's a VP of tech dev his opinion should count for something on these internet forums realms :P

    -- and by the way --

    I've been working with ORMs and SQL-mappers for a while now (a long while). Hibernate, iBatis, in-house developed, you name it. I know for experience what you can and cannot do. I still have to see an application with high volume of RDMB traffic being able to use a ORM without having to add extra layers of L1/L2 application caching, making the whole thing a big, fat lasagna architecture.

    Complexity for the sake of just using yet a new flashing toy is not engineering.
    Don't take this as an attempt to agree that stored procedures are unnecessary, but Nagesh is technically 99.99% right. If an ORM simply submits blobs of parameterized and prepared SQL that are exactly the same as the contents of the stored procedures you would have developed, then the only difference would be an increase in the size of the requests. Not that any well-known ORM would create exactly the right SQL, but a custom developed one certainly could.

    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.
  • Ajtacka 2011-01-27 12:35
    trwtf:
    Because the question wasn't "what was the most interesting job you've ever had", it was "what is the most interesting thing you've ever worked on". I think your phrase - "not remotely relevant" is the right one.

    The fail wasn't necessarily in mentioning the job, it was in misunderstanding the question.


    I get (maybe) that misunderstanding a question might cut the candidate out of the running for the job. But that in itself doesn't justify firing the recruitment company! Is taking pictures of naked people really that offensive? (assuming this happened in a country where the adult industry is legal - otherwise mentioning it is absolutely a wtf)
  • trwtf 2011-01-27 12:45
    Tim G:
    trwtf:
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?

    Because the question wasn't "what was the most interesting job you've ever had", it was "what is the most interesting thing you've ever worked on". I think your phrase - "not remotely relevant" is the right one.

    I don't disagree with you, but that's not what Matthew seems to be saying, which is that the fact that talking about one's work in the adult film industry isn't appropriate in some kind of inherent sense. Which is bullshit.


    Fair enough - there are some interviews where I wouldn't bring it up, but there's nothing inherently wrong with it.

    As a matter of tactics, it's something you'd want to deploy only if you had a very good reason to think it was the right thing to talk about at that moment, and if you thought you could get away with it.
    When someone asks the interviewer how the interview went, you want them to be saying "Man, the guy knows his stuff, and he's done all kinds of interesting stuff too" not "It was a little weird, I asked him about what sort of work he'd done and he started going on about taking porn pictures".
  • MichaelWojcik 2011-01-27 12:54
    Nagesh Kukunoor:

    I met him on a coffee break. We have coffee breaks four times a day. We don't actually drink coffee, since the canteen boy doesn't always deliver coffee on time. We talk about IT trends.


    It's all a rich tapestry.

    Nagesh, if you're going to troll, do try to make it interesting, eh? See the David Thorne bit someone posted earlier. Now there's a man who knows how to troll. (Learn more from Thorne at 27b/6.)

    It's shadows in a vacuum, man. Shadows in a vacuum.
  • luis.espinal 2011-01-27 13:03
    Jaime:
    Don't take this as an attempt to agree that stored procedures are unnecessary, but Nagesh is technically 99.99% right. If an ORM simply submits blobs of parameterized and prepared SQL that are exactly the same as the contents of the stored procedures you would have developed, then the only difference would be an increase in the size of the requests. Not that any well-known ORM would create exactly the right SQL, but a custom developed one certainly could.

    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.


    Now, this is an counter-argument with some thought. Thank you. I don't necessarily defend stored procedures from the point of view of speed (or criticize ORM's from the point of view of slow-downs.) In fact, if someone is using stored procedures to squeeze functionally necessary speed, chances are there is something wrong with the whole architecture. BTW, my preferred usage of stored procedures has been in terms of security (security in depth), not speed. Not something that is generally applicable, though.

    My take against Nagesh's POV is that he hasn't explained why ORMs are the way of the future (something debatable) or why stored procedures are a thing of the past (something 100% falsifiable.) I really have to disagree with you that Nagesh is 99.99% right... he hasn't made a technical point at all.

    In fact, Nagesh's argument that ORMs made stored procedures irrelevant does not make any sense. The ORM layer separates application from SQL access, and SQL can include legitimate access to stored procedures (a form of vendor specific construct supported by that vendor's implementation of SQL.) A legitimate existence of a stored procedure is (typically) independent of the usage (or not usage) of a ORM. Furthermore, correct usage of a ORM typically depends on A) good knowledge of SQL, and B) appropriate knowledge of the client's database characteristics (good or bad).

    From an application view, the ORM is all there is. But for whoever implements and maintains the specific ORM mappings, he/she better know his SQL and his client's db well (including stored procedures if they exist.) So Nagesh's argument makes no sense technically speaking.

    Very few people actually know how to use a ORM (sadly). As a consultant, I've been asked a couple of times to do review systems that are seriously deteriorated (in terms of speed and/or memory/connection usage). Many a time is the misapplication or misuse of ORMS (Hibernate in particular)... that in combination with other factors obviously.

    Most people know ORMs (and SQL) just superficially, and they are unwilling (or incapable) of doing an objective trade-off analysis.

    Sometimes, the best (or most appropriate) solution is to simply operate on a result set (as opposed to an object graph build either manually or with a ORM). But that doesn't look as good in a resume as, say using Hibernate. And you see that all the time, systems glued together with ORMs, JMS, ESB and whatever new shiny toy around the block... in cases where they didn't need most (if any of it) at all.

    That's not engineering, that's just playing games at the employer's expense for the purpose of padding one's resume. That's unethical.

    Sorry for the long rant, I just don't see Nagesh having made any valid technical point at all.
  • BigJim 2011-01-27 13:17
    Agree with you 100% - more if that were possible. As a consultant you don't always get to dictate the environment. Several years ago at a company that produces adult beverages (no fear in mentioning that job, right?) - the environment had NO application code, it was all ran through stored procedures.

    Right or wrong, the job was to go in and modify those. All business logic was in stored procs - such as, 3000+ line long procs that are themselves candidates for WTF-ness.

    My point is, flexibility is key - ORM's are useful, but not the be-all and end-all. Stored proc knowledge is a *must*, just like "knowing about databases" is a must.

    Here's another argument for stored procs. IF you keep code in a stored proc, then an update can be made by pushing that proc to production. No code change/deployment needed. Depending on the environment, this might be an easier thing to push through all the gate-keepers - dba's, data center, etc. - involved in a "production fix".
  • SCSimmons 2011-01-27 13:31
    Delicious pie is delicious.:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?

    Yeah, it really is a bit like asking an imperative programmer, "so, how about those user-defined functions?" Or like asking a truck driver, "so how do you feel about steering wheels?"

    Oh. So the theory is that stored procedures are so key to the SQL Server database developer job, that nobody would even be applying for a position like that if they weren't very familiar with them. So why bother asking?

    As someone who has interviewed candidates for SQL Server database developer positions, I find it difficult to respond to this in any other way than pointing and laughing.
  • lesle 2011-01-27 13:32
    Re: Shadows in a Vacuum.

    <a href="http://www.jtkdev.com/light.html">Dark in the Vacuum</a>
  • boog 2011-01-27 13:33
    Jaime:
    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims.
    When did it become erroneous to make falsifiable claims? Why did no one tell me?

    Jaime:
    There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.
    Am I the only one who uses stored procedures for more than just SQL queries? I believe database views already cover that area.
  • Capt. Obvious 2011-01-27 13:40
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.

    Germany doesn't have a large group of visually distinctive people who are often discriminated against... at least not like the US does. The number of ethnic minorities in Germany is smaller and they seem to be more evenly distributed socio-economically.

    If your concern is privacy, the photos on the resume seem reasonable. If your worry is that black/latino people won't get an interview, it seems like forbidding them is a legit idea.
  • Migala 2011-01-27 13:41
    stibbons:
    together with a non-returnable photograph to careers@-------.com


    So what happens if your email bounces?


    Then clearly you failed to send a non-returnable photograph, and you won't get the job.
  • History Agent 2011-01-27 13:43
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    There's irony for you. I wonder if WWII had anything to say about that.
  • frits 2011-01-27 13:44
    History Agent:
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    ...anymore.


    FTFY
  • trwtf 2011-01-27 13:47
    Capt. Obvious:
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.

    Germany doesn't have a large group of visually distinctive people who are often discriminated against... at least not like the US does.



    Unless, of course, you count the Turks.
  • History Agent 2011-01-27 13:48
    frits:
    History Agent:
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    ...anymore.


    FTFY

    Thanks. After I hit submit, I realized that using the word "irony" set off troll detectors all over the land.
  • Nagesh Kukunoor 2011-01-27 14:06
    MichaelWojcik:
    Nagesh Kukunoor:

    I met him on a coffee break. We have coffee breaks four times a day. We don't actually drink coffee, since the canteen boy doesn't always deliver coffee on time. We talk about IT trends.


    It's all a rich tapestry.

    Nagesh, if you're going to troll, do try to make it interesting, eh? See the David Thorne bit someone posted earlier. Now there's a man who knows how to troll. (Learn more from Thorne at 27b/6.)

    It's shadows in a vacuum, man. Shadows in a vacuum.


    I am not able to open this website. Our company filters have blocked it. Are you trying to get me fired?
  • Aaron 2011-01-27 14:08
    The non-returnable picture is probably just a cut & paste that didn't get fully updated from the days when they handled paper resumes.
  • Abso 2011-01-27 14:36
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?

    Being able to follow cultural conventions around taboo subjects is an important social skill, regardless of whether that taboo makes sense. People who lack important social skills don't make great employees.
  • TW 2011-01-27 14:38
    frits:
    History Agent:
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    ...anymore.


    FTFY


    Is it time to start a Godwin pool?
  • CnC 2011-01-27 14:49
    I find stored procedures useful because so often in big companies the application guys aren't database oriented and thus make design decisions that fail to utilize the horsepower of a big database (see Exadata2). And a database developer using something like PL/SQL can leverage the power more effectively by hiding that complexity from the app developers.
  • Tim G 2011-01-27 14:54
    trwtf:
    When someone asks the interviewer how the interview went, you want them to be saying "Man, the guy knows his stuff, and he's done all kinds of interesting stuff too" not "It was a little weird, I asked him about what sort of work he'd done and he started going on about taking porn pictures".

    But if you've got good skills, it could also be the thing that makes you stand out as a human being with a personality who does something other than code all day and night. That sort of thing matters to some people -- I'm reminded of Eric Lippert's Laugh While You Can, Monkey Boy!
    Abso:
    Being able to follow cultural conventions around taboo subjects is an important social skill, regardless of whether that taboo makes sense. People who lack important social skills don't make great employees.

    We're not talking about someone who dropped the F-bomb 60 times or who talked about his masturbation habits in an interview here. We're talking about someone who mentioned an odd point in their work history, and to anyone other than a Victorian prude or the HR Director of a Fortune 500 (same thing), it should be an amusing anecdote if the interview is otherwise going well. Let me guess, if the guy worked as a programmer for an adult website, you wouldn't want him to mention that either.
  • Zylon 2011-01-27 15:05
    History Agent:
    Thanks. After I hit submit, I realized that using the word "irony" set off troll detectors all over the land.

    The fact that you were responding to a post from "Captain Obvious" should have been the first clue that your post was going to be an exercise in redundancy.
  • boog 2011-01-27 15:06
    Abso:
    Being able to follow cultural conventions around taboo subjects is an important social skill, regardless of whether that taboo makes sense. People who lack important social skills don't make great employers.

    FTFY
  • trwtf 2011-01-27 15:23
    Tim G:
    trwtf:
    When someone asks the interviewer how the interview went, you want them to be saying "Man, the guy knows his stuff, and he's done all kinds of interesting stuff too" not "It was a little weird, I asked him about what sort of work he'd done and he started going on about taking porn pictures".

    But if you've got good skills, it could also be the thing that makes you stand out as a human being with a personality who does something other than code all day and night.


    Yes, exactly. Handled correctly, you get my first case. Handled badly, you get the second. Either way, you stand out, but one way helps you, the other does not.

    I don't think we're really disagreeing on this. I'm just emphasizing the "caution" part of it. It'd be easy to blow an otherwise good interview by seeming like a potential problem employee.
    For example, you could easily mishandle this and create the impression that you're a potential harrassment suit. For another example, you don't want your interviewer to be wondering whether you'd be the guy surfing porn sites in the office. Either of those would probably put you on the "no" pile, no matter how good a programmer you are.
  • Tim G 2011-01-27 15:43
    trwtf:
    Yes, exactly. Handled correctly, you get my first case. Handled badly, you get the second. Either way, you stand out, but one way helps you, the other does not.

    I don't think we're really disagreeing on this. I'm just emphasizing the "caution" part of it. It'd be easy to blow an otherwise good interview by seeming like a potential problem employee.

    Fair enough. I may be leaning towards the less cautious side because a) I don't interview much, and b) I've been phone-interviewing candidates all day and they all evidence more-or-less the same skills, so personality is counting for a lot.
  • Fennec 2011-01-27 15:46
    luis.espinal:
    When people start saying "death to this or that", it indicates they might not have a firm grasp on the technical issues at hand.


    Death to Mork.



    ...
    (hi. i am not spam. hi. i am not spam. seriously now.)
  • smxlong 2011-01-27 15:56
    Attach a photograph? This must not have been in the US. According to HR folks I've spoken with, any resume that arrives with a photograph attached goes directly in the trash. Apparently, it pollutes the hiring process by opening the possibility of discrimination based on race.

    When I mentioned that a person's race could often be guessed just by what their name is, they shrugged and said "Doesn't make any sense, but those are the rules."

    If you want a US job, attaching a photo to your application is a good way to not get hired.
  • Rob White 2011-01-27 16:02
    smxlong:
    Attach a photograph? This must not have been in the US. According to HR folks I've spoken with, any resume that arrives with a photograph attached goes directly in the trash. Apparently, it pollutes the hiring process by opening the possibility of discrimination based on race.

    When I mentioned that a person's race could often be guessed just by what their name is, they shrugged and said "Doesn't make any sense, but those are the rules."

    If you want a US job, attaching a photo to your application is a good way to not get hired.


    OK smart guy, what race am I?
  • Bub 2011-01-27 16:03
    Should I keep my tale of college summers spent manually extracting bull semen quiet?

    Or just bring a bottle of hand-sanitizer along to offer them?
  • Bub 2011-01-27 16:04
    Rob White:
    smxlong:
    Attach a photograph? This must not have been in the US. According to HR folks I've spoken with, any resume that arrives with a photograph attached goes directly in the trash. Apparently, it pollutes the hiring process by opening the possibility of discrimination based on race.

    When I mentioned that a person's race could often be guessed just by what their name is, they shrugged and said "Doesn't make any sense, but those are the rules."

    If you want a US job, attaching a photo to your application is a good way to not get hired.


    OK smart guy, what race am I?


    Clearly you're a homosexual polynesian dwarf. With jug ears.
  • Capt. Obvious 2011-01-27 16:05
    trwtf:
    Capt. Obvious:
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.

    Germany doesn't have a large group of visually distinctive people who are often discriminated against... at least not like the US does.



    Unless, of course, you count the Turks.

    At 3% of the population, I considered the Turks. But that's only 3%. It's not like the US with its substantial black and latino populations (12.5% and 10%). The US has a higher percentage Asian people (4.5%) and multiracial people than Germany does Turks. Hell, the US has more Native Americans than the Germany has Turks, in absolute numbers.

    It's hard to talk about Germany's racial uniformity without skating the Godwin line. However, looking at France, it's only slightly more diverse (with a 5.25% of the population coming from Northern Africa and 1.75% from the rest of Africa... although only about 3% of France is black.) Turks only make up 0.7% of the French population.
  • Matt Westwood 2011-01-27 16:12
    trwtf:
    Tim G:
    trwtf:
    When someone asks the interviewer how the interview went, you want them to be saying "Man, the guy knows his stuff, and he's done all kinds of interesting stuff too" not "It was a little weird, I asked him about what sort of work he'd done and he started going on about taking porn pictures".

    But if you've got good skills, it could also be the thing that makes you stand out as a human being with a personality who does something other than code all day and night.


    Yes, exactly. Handled correctly, you get my first case. Handled badly, you get the second. Either way, you stand out, but one way helps you, the other does not.

    I don't think we're really disagreeing on this. I'm just emphasizing the "caution" part of it. It'd be easy to blow an otherwise good interview by seeming like a potential problem employee.
    For example, you could easily mishandle this and create the impression that you're a potential harrassment suit. For another example, you don't want your interviewer to be wondering whether you'd be the guy surfing porn sites in the office. Either of those would probably put you on the "no" pile, no matter how good a programmer you are.


    I dunno - if you've been up close and personal for a career, the *last* thing you'd be likely to do is want to spend all your time looking at *pictures* of it all ... take it from one who knows. Er, so to speak.
  • smxlong 2011-01-27 16:13
    I said could OFTEN be guessed. In case it wasn't obvious enough, I think the whole issue is moronic anyway.
  • Matt Westwood 2011-01-27 16:15
    Abso:
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?

    Being able to follow cultural conventions around taboo subjects is an important social skill, regardless of whether that taboo makes sense. People who lack important social skills don't make great employees.


    Come to think of it, I wouldn't want to work for people who are prudish like that, it would put too much of a crimp on interpersonal banter and freedom of expression.
  • Jake 2011-01-27 16:37
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?
    Because if you've ever even seen a real live naked woman (even if you were paid to do it) you're clearly not going to fit in with your co-workers in IT.
  • Matt Westwood 2011-01-27 16:49
    Jake:
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?
    Because if you've ever even seen a real live naked woman (even if you were paid to do it) you're clearly not going to fit in with your co-workers in IT.


    +1 pml
  • Herby 2011-01-27 16:53
    Is it just me?

    Why not combine two of these experiences and submit one of those pictures that "the porn guy" took as the "non-returnable photo". Might just work, you never know.

    Yes, in the USA, not including the picture is more for the protection of the EMPLOYER, not the candidate. If they don't have it, they can't be blamed. Times have changed. College applications of the 60's routinely asked for a picture (I don't know about now!).
  • Vombatus 2011-01-27 17:03
    trwtf:

    ...It might be different if you're interviewing with Nicholas Parsons, but that's kettle of fish of a different color.

    Coincidently, I was listening to Just A Minute when I read this.
  • hoodaticus 2011-01-27 17:04
    anon:
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.


    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.
    Good answer! Do you have a J.D. like me?

    Federally, the categories are race, color, religion, sex, and national origin. States are therefore free to permit discrimination based on gender, sexual orientation, and any other category you can think of. Yes, you can be fired in many if not most states for being gay or identifying yourself as a gender that does not match your sex.

    In addition, you can discriminate based on any category - including race - if membership in the class is a bone fide occupational qualification (BFOQ). For example, BET can probably get away with only hiring black people to be on the air. Off the air, they probably could not.
  • hoodaticus 2011-01-27 17:05
    Jake:
    Tim G:
    Matthew:
    Also, you could deduce certain things from somebody thinking that talking about their past in the adult film industry is appropriate in a job interview.

    Why isn't it, exactly? I mean, I don't talk much about my high-school job history as a arcade game repairman in my interviews because it's not remotely relevant to what I do. But if I were asked something that brought it up, I might mention it in passing. Why should it be any different in this case?
    Because if you've ever even seen a real live naked woman (even if you were paid to do it) you're clearly not going to fit in with your co-workers in IT.
    Nice! Dude clearly didn't factor in that these people are total nerds.
  • ÃÆâ€â„ 2011-01-27 17:09
    Bub:
    Should I keep my tale of college summers spent manually extracting bull semen quiet?

    Or just bring a bottle of hand-sanitizer along to offer them?

    So you're the porn guy I saw on...
  • hoodaticus 2011-01-27 17:11
    TW:
    frits:
    History Agent:
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    ...anymore.


    FTFY


    Is it time to start a Godwin pool?
    Hitler simile blah blah.
  • hoodaticus 2011-01-27 17:36
    boog:
    Jaime:
    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims.
    When did it become erroneous to make falsifiable claims? Why did no one tell me?

    Jaime:
    There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.
    Am I the only one who uses stored procedures for more than just SQL queries? I believe database views already cover that area.
    Okay, you're like my favorite commenter here now, boog. You and frits and Moebius.
  • Dirge 2011-01-27 17:48
    Jaime:

    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.


    Ad-hoc SQL is never going to have the execution plan(s) pre-built on the server side, is it? If not, there's a performance hit right there.

    I can't speak for Oracle, but on SQL Server, stored procedures are great. They provide all sorts of opportunities to do processing on the DB server, instead of sending masses of data back and forth between the DB server and app server. The people who develop database software specialize in optimizing it for what it does, so why not let that software do that work for you instead of trying to code it yourself?

    Tools like LINQ make it easier to do database-style processing off of the server, but it still seems wasteful to do that given the choice between processing in-place and offloading processing to the (probably-not-written-as-well-as-SQL-Server) application tier.
  • other 2011-01-27 17:54
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.


    Here in the USA, that's the most legal reason not to hire someone. What good are past-job references unless employers can use them to deny a job?

    ... and that guy who played Barney Miller is dead, I think.
  • Harrow 2011-01-27 18:15
    TPG:
    pjt33:
    backForMore:
    Don't bother posting without a non-returnable photograph.

    Does it have to be a photograph of me?


    I've got some very tasteful pictures of my girlfriend I took just out of high-school. Would one of those work?

    It depends -- just how tasty is she?

    I too can misunderstand a word if I want to.

    -Harrow.
  • luis.espinal 2011-01-27 18:17
    other:
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.


    Here in the USA, that's the most legal reason not to hire someone. What good are past-job references unless employers can use them to deny a job?

    ... and that guy who played Barney Miller is dead, I think.


    We can go even further than that. In the US, it is legal to decline hiring someone based on his/her credit history. The only criteria that are actionable/protected are gender, race/nationality, religion, political views and (to a degree) sexual inclination, age, handicap status and past criminal record. Everything else is free game for hiring or not hiring someone.

    With that said, the days when people were discriminated for minutia is long gone. It is rare (though still occurs). Every country is different, and when you are in that country, you *do* as in that country. And in this country, it is not appropriate (or wise) to talk about having any type of work with ZOMG! pr0nX0rs! regardless of how easy going the interviewers might be.

    Maybe one can talk about it after getting the job... and only in work circumstances that are welcome, permissible and judicious. In life, no matter what country you are, it pays to keep your pie hole shut when at work.

    Freedom of expression is best left when you punch out of work, not when you are in. Freedom of expression is not going to take a dent from keeping one's mouth shut while on the clock.

    The only time I could think someone should/could talk about such type of past work is if that person is interviewing for a job related to online billing and charging or media streaming (where pr0n is supreme and leads the way.)

  • Jim Howard 2011-01-27 18:18
    I worked in the UK about 15 years ago, so things might have changed, but then age discrimination was very legal and normal.

    Applicant age was prominently mentioned in almost every employment advertisement. You'd see something like 'Java programmer with five years experience, should be between 20 and 30 years of age'.

    Here in the United States people over 40 are a protected group, along with veterans, felons, and people descended from Spain. Oddly people of Portuguese descent are not a protected group.

    Go figure.
  • Ron 2011-01-27 18:39
    Jim Howard:
    Here in the United States people over 40 are a protected group, along with veterans, felons, and people descended from Spain. Oddly people of Portuguese descent are not a protected group.

    Go figure.
    It's because we all know the Spaniards "need a little help" while the Ports are just as good as anyone else.

    There, see? Segregating people by some arbitrary group and saying "you can't discriminate against these people" is discrimination! And it perpetuates the idea that some people -- not individuals, but groups -- are weaker, and couldn't make it on their own.

    I have a dream... that someday people will not be judged for the color of their skin, but for the content of their character. Radical, I know.
  • Jaime 2011-01-27 18:52
    Dirge:
    Jaime:

    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.


    Ad-hoc SQL is never going to have the execution plan(s) pre-built on the server side, is it? If not, there's a performance hit right there.

    I can't speak for Oracle, but on SQL Server, stored procedures are great. They provide all sorts of opportunities to do processing on the DB server, instead of sending masses of data back and forth between the DB server and app server. The people who develop database software specialize in optimizing it for what it does, so why not let that software do that work for you instead of trying to code it yourself?

    Tools like LINQ make it easier to do database-style processing off of the server, but it still seems wasteful to do that given the choice between processing in-place and offloading processing to the (probably-not-written-as-well-as-SQL-Server) application tier.
    You couldn't be more wrong. Microsoft SQL Server has cached execution plans for ad-hoc SQL for the past fourteen years. Also, ad-hoc SQL runs on the server too. There is nothing preventing one from submitting 128MB of text as ad-hoc SQL and it running on the server. From that perspective, there is zero difference between stored procedures and ad-hoc SQL. Your argument is that exact argument that I was referring to in my post. It only serves to show that you only know one side of the argument. When you come up with an argument that actually holds water, come back and try it.
  • Jaime 2011-01-27 18:59
    boog:
    Jaime:
    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims.
    When did it become erroneous to make falsifiable claims? Why did no one tell me?

    Jaime:
    There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.
    Am I the only one who uses stored procedures for more than just SQL queries? I believe database views already cover that area.
    OK, so I could have used a better word like "disproven" instead of "falsifiable". Congratulations for winning the vocabulary war. Now back to SQL...

    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.

    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.
  • Jaime 2011-01-27 19:04
    BigJim:
    Here's another argument for stored procs. IF you keep code in a stored proc, then an update can be made by pushing that proc to production. No code change/deployment needed. Depending on the environment, this might be an easier thing to push through all the gate-keepers - dba's, data center, etc. - involved in a "production fix".
    So your big plus for stored proces is that they are easy to sneak around the change control process. Are you sure that's a good thing? You could use the same argument to show that it's a good idea for production code to call a script stored in your home directory.
  • Power Troll 2011-01-27 19:08
    frits:
    History Agent:
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    ...anymore.


    FTFY


    Why is this not blue?
  • cone 2011-01-27 20:27
    That one had me rollin'.

    Sounds silly, but before I realized what they were and had to write a few, I thought stored procedures were the functions we wrote for the database (from say PHP). Can you tell I started on MySQL?

    captcha: paratus .. a wha?
  • Vlad Patryshev 2011-01-27 20:58
    Not exactly porn, but I once tried a stunt with a company where I was interviewing but actually did not want to go. They asked for a reference, and I gave them my former manager, just out of curiosity, what happens if they get a mixed response, and also how do people give this kind of mixed responses?

    So a couple of days later they bothered to invite me again for a casual lunch talk, and started grilling me regarding my personal traits. I hardly concealed my smile, and was just curious, what exactly went wrong etc.

    So now I know how it works.

    Then the recruiter asked me what happened, and again, out of curiosity, I told him what happened. "You are very smart" he said. Probably in their language it means "you are an idiot". (Well, 23andme recently told me that not caring about negative response is in my genes...)
  • Gunslinger 2011-01-27 21:18
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.


    Actually, the issue is that it's difficult for anyone to send an unreturnable photo by email.
  • Gunslinger 2011-01-27 21:21
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?


    If you're not working with an embedded system, you probably don't care about atomic operations, and if you are working with an embedded system, you're likely to need to know what one is.
  • moz 2011-01-27 21:30
    Safely anonymous:
    And of course, the onus is on *you* to prove that you weren't hired because of one of the "naughty" categories. As long as they can come up with a reasonable explanation, they're off the hook.

    That's a shame (although the tolerance the USA has for racist politicians is probably worse). In the UK, the courts tend to look unfavourably on an employer who doesn't have clear enough notes on each interview to show that the decision was not taken on an unlawful basis.

    That said, candidates rarely find out why they have been rejected. And I don't suppose previously having held a job as a porn camerawoman would break the law (in the way that, say, rejecting an ex-soldier could do).
  • uuang 2011-01-27 21:36
    I love tales from the interview.
  • Curious George 2011-01-27 22:09
    Jaime:
    Dirge:
    Jaime:

    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.


    Ad-hoc SQL is never going to have the execution plan(s) pre-built on the server side, is it? If not, there's a performance hit right there.

    I can't speak for Oracle, but on SQL Server, stored procedures are great. They provide all sorts of opportunities to do processing on the DB server, instead of sending masses of data back and forth between the DB server and app server. The people who develop database software specialize in optimizing it for what it does, so why not let that software do that work for you instead of trying to code it yourself?

    Tools like LINQ make it easier to do database-style processing off of the server, but it still seems wasteful to do that given the choice between processing in-place and offloading processing to the (probably-not-written-as-well-as-SQL-Server) application tier.
    You couldn't be more wrong. Microsoft SQL Server has cached execution plans for ad-hoc SQL for the past fourteen years. Also, ad-hoc SQL runs on the server too. There is nothing preventing one from submitting 128MB of text as ad-hoc SQL and it running on the server. From that perspective, there is zero difference between stored procedures and ad-hoc SQL. Your argument is that exact argument that I was referring to in my post. It only serves to show that you only know one side of the argument. When you come up with an argument that actually holds water, come back and try it.

    I was curious so I looked it up on msdn...


    ...
    When a user process inserts an execution plan into the cache, the user process sets the current cost equal to the original query compile cost; for ad-hoc execution plans, the user process sets the current cost to zero.
    ...
    The following examples illustrate which execution plans get removed from the procedure cache:

    *

    An execution plan is frequently referenced so that its cost never goes to zero. The plan remains in the procedure cache and is not removed unless there is memory pressure and the current cost is zero.
    *

    An ad-hoc execution plan is inserted and is not referenced again before memory pressure exists. Since ad-hoc plans are initialized with a current cost of zero, when the database engine examines the execution plan, it will see the zero current cost and remove the plan from the procedure cache. The ad-hoc execution plan remains in the procedure cache with a zero current cost when memory pressure does not exist.


    ...so it looks to me that if the adhoc query is being looped, it'll eventually get costed, else it'll get flushed.
  • frits 2011-01-27 22:59
    Power Troll:
    frits:
    History Agent:
    Capt. Obvious:

    Germany doesn't have a large group of visually distinctive people who are often discriminated against...

    ...anymore.


    FTFY


    Why is this not blue?


    Probably too racey.
  • Dave 2011-01-27 23:43
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures


    Naah, just write your own database drivers. It should only take about six weeks.
  • Dave 2011-01-27 23:49
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"

    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?


    The company obviously built process controllers for nuclear power plants. Geeze, do I have to do all the thinking around here?
  • Dave 2011-01-27 23:59
    The Corrector:
    goob:
    Ok. Let's review:

    1) Liz gets job and goes to college.
    2) Liz interviews for new job, putting past job on resume.
    3) Company blacklists Liz based purely on the answer to a seemingly-benign interview question.
    3.1) Company adds insult to injury by calling her a guy.
    4) Liz gets a new job.
    5) Liz interviews candidate.
    6) Liz blacklists candidate based purely on the answer to a seemingly-benign interview question.

    FTFY


    Oh for fscks sake will people stop going on about Uncle Liz being a woman! For one thing it's upsetting Aunty Steve.
  • Henning Makholm 2011-01-28 00:39
    Gunslinger:
    Henning Makholm:
    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    If you're not working with an embedded system, you probably don't care about atomic operations, and if you are working with an embedded system, you're likely to need to know what one is.

    Hm. I don't work with embedded systems (much), yet somehow I do care.

    On the other hand, some of what I do is a language runtime.

    On the other-other hand, I would expect that an embedded system whose OS is so rudimentary that it doesn't offer application programmers the usual suite of concurrency primitives would be a single-core affair where atomicity is relatively simple -- no worrying about memory hierarchies and using the right kind of barrier. But I don't actually know that, no.
  • grumpy 2011-01-28 04:35
    Paco:
    It's sad that people are such prudes. If it were me interviewing that guy would have moved to the top of the list.

    I agree. Anyone willing to do what it takes to get through a tight spot will be good to have on the team. At least he's not going to balk at doing luser support - he's done stuff at least as mindnumbing before.
  • Matthew 2011-01-28 05:21
    Tim G:

    I don't disagree with you, but that's not what Matthew seems to be saying, which is that the fact that talking about one's work in the adult film industry isn't appropriate in some kind of inherent sense. Which is bullshit.


    I mean that context matters. Talking about it in passing is fine. I personally don't have a problem with it - but I think mentioning it in an interview shows poor judgement. Do you want to employ people with poor judgement?

  • sql guy 2011-01-28 05:33
    Nagesh Kukunoor:
    hoodaticus:
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.
    If you have ever written a stored procedure in your life, you would not forget what they are.


    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.


    Think of it like this, in OO terms:

    The database is your "object".

    Its tables are your object's "fields".

    Stored Procedures are your objects "methods".

    In general you want to keep your object's field hidden from outside view, and only access them through methods.

    I write and maintain many database applications and I can tell you ones that don't use stored procedures are a nightmare to maintain from a database point of view. You have ad-hoc queries hitting the database instead of a fixed list of procedures, and keeping track of what indexes are needed and optimising the data access is made far for difficult.
  • Drak 2011-01-28 05:44
    Jaime:
    boog:
    Jaime:
    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims.
    When did it become erroneous to make falsifiable claims? Why did no one tell me?

    Jaime:
    There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.
    Am I the only one who uses stored procedures for more than just SQL queries? I believe database views already cover that area.
    OK, so I could have used a better word like "disproven" instead of "falsifiable". Congratulations for winning the vocabulary war. Now back to SQL...

    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.

    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.


    CREATE PROCEDURE Something
    @intI AS INTEGER
    AS
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here, can't be arsed for this example. Obviously just adding 1 to a variable doesn't require recursion, but some things seem to be more easily programmed recursively.
    IF @intI < 600
    EXEC Something @intI
    END
  • BigJim 2011-01-28 06:25
    Jaime:
    BigJim:
    Here's another argument for stored procs. IF you keep code in a stored proc, then an update can be made by pushing that proc to production. No code change/deployment needed. Depending on the environment, this might be an easier thing to push through all the gate-keepers - dba's, data center, etc. - involved in a "production fix".
    So your big plus for stored proces is that they are easy to sneak around the change control process. Are you sure that's a good thing? You could use the same argument to show that it's a good idea for production code to call a script stored in your home directory.


    I did not say I didn't go thru the change process, I just mean that the change process for DBA-level changes *in all shops I've been in-not everywhere* is less fraught with bureaucratic overhead
  • sql guy 2011-01-28 06:34
    Dirge:
    Jaime:

    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.


    Ad-hoc SQL is never going to have the execution plan(s) pre-built on the server side, is it? If not, there's a performance hit right there.


    I'm a big fan of stored procedures, but I think SQL Server will try to cache the compiled SQL and query plan for ad-hoc queries if it can. So whilst performance was a big issue at one time, it is less of one now.

    Even so, I'd still recommend stored procedures for security, ease of monitoring how the database is accessed, flexibility to change the underlying tables as long as the stored procedure is left unchanged, ability to use several steps to return result sets if this is more efficient, etc.
  • eric76 2011-01-28 08:11
    anon:
    The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.
    I was hired at my first job after college because I had a beard.

    They had narrowed it down to two of us. Since everyone there had a beard, I had a beard, and the other applicant didn't, I got the job.
  • M 2011-01-28 08:12
    I found stored procedures are very useful to getting performance back where Linq to SQL just dies on its arse.

    One example is searching a set of products based on name, code, manufacturer etc. These are all "OR" operations, building it in linq was painful and took a few seconds to execute. Writing it in a stored procedure reduced this to 60 odd milliseconds!

    So optimise where necessary I guess.
  • will 2011-01-28 08:20
    [quote user="Dirge"][quote user="Jaime"]
    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims. Simply claiming that stored procedures are faster is not good enough. There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.[/quote]

    Ad-hoc SQL is never going to have the execution plan(s) pre-built on the server side, is it? If not, there's a performance hit right there.

    I can't speak for Oracle, but on SQL Server, stored procedures are great. They provide all sorts of opportunities to do processing on the DB server, instead of sending masses of data back and forth between the DB server and app server. The people who develop database software specialize in optimizing it for what it does, so why not let that software do that work for you instead of trying to code it yourself?

    [quote]
    Since we are speaking MS-SQL Server, they have not pre-compiled for over 10 years, yes it has been over a decade since that statment that stored procedures are treated different then ad-hoc sql could be truthfully said about a recent software version. Some difference for CLR stored procedures.

    As for optimizing database call go read up on high performance tuning and papers from places like amazon or google they all say the same thing ditch stored procedures.
    The truth is where stored procedures are used for CRUD in most cases they are alot slower then dyanamic parameterized SQL. The reason is they are full of ISNULL, COALEASE and CASE statments any they are slow, slow, slow. 10 years ago this was not the case and your statement is true.

    The one main place where do see performance boost of dynamic parameterized SQL is in your example where you are having to process pass a bunch of data back and forth so that you can come up with a simple number. In that case yes stored procedures are probably the best thing to use, but then those cases are rare compared to all the simple CRUD that happens.
  • eric76 2011-01-28 08:30
    Bub:
    Should I keep my tale of college summers spent manually extracting bull semen quiet?

    Or just bring a bottle of hand-sanitizer along to offer them?
    When a friend of mine was in college in Lousiana in the early 1970s, he was in a dorm room talking to a friend of his and mentioned an upcoming course in AI.

    The friends roommate was sitting nearby and got really irate at the mention of the AI course.

    It turned out that he was ticked off to find that they had a course in Artificial Insemination in Computer Science when they didn't have one in Agriculture that he could take for his degree.
  • Tim G 2011-01-28 08:39
    Matthew:
    Tim G:
    I don't disagree with you, but that's not what Matthew seems to be saying, which is that the fact that talking about one's work in the adult film industry isn't appropriate in some kind of inherent sense. Which is bullshit.

    I mean that context matters. Talking about it in passing is fine. I personally don't have a problem with it - but I think mentioning it in an interview shows poor judgement. Do you want to employ people with poor judgement?

    Let's look at the scenario again:
    and found my way to a fairly casual lunch interview. After asking a slew of technical questions, one of the interviewers asked me what was the most interesting thing I ever worked on. I struggled to think of something. Up to that point I had only done really boring in-house apps and lots of SQL queries. <snip> I’m often hesitant to discuss it, but the guys seemed like open-minded young males who wouldn’t take offense to it.<snip> They seemed intrigued, and things seemed to go well after that."

    Taking the OP at face value (which, admittedly, is a shakey proposition), it doesn't look like we're talking about someone with generally poor judgement. It looks like we're talking about someone who, under pressure and feeling nervous, considered the situation and made a judgement call and happened to be wrong. Would I have made the same call? Probably not. But I also wouldn't jump to condemn someone as not having social skills or being inappropriate based on that.

    I spent most of the day yesterday and I'm going to spend most of the day today doing phone interviews. If I circular-filed every resume because the candidate was awkward or made some kind of minor social snafu, I wouldn't have anyone left. With respect to appropriate behavior, there's a big gulf between "candidate mentioned during a casual interview that was going well that he/she once had a job in a mildly taboo industry" and "candidate was an argumentative asshole, or candidate whined during the interview that the questions were too hard [this just happened to me], or candidate smelled bad and picked his toes during interview."

    If it comes down to you and one other person, and you mentioned something like that and the people you were interviewing with wanted to take it into account, might it cost you the interview? Sure. But there are lots of places to interview with out there.
  • Billy Goat Gruff The Lesser 2011-01-28 08:41
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.


    Perhaps you could try reading up on, say, actual laws?

    Discrimination is legal on any grounds except the ones that are illegal, such as : -

    Age (unless they're too old / young / inexperienced / experienced)

    Gender (unless they're the wrong gender)

    Sexuality (unless they're just too unsexy or you're in one of those countries where sex is illegal & immoral; Saudi Arabia, Pakistan, America...)

    Disability (unless they're, like, a freak?)

    ;)
  • Billy Goat Gruff The Lesser 2011-01-28 08:45
    Nagesh Kukunoor:
    My experience tells me that stored procedures are a thing of the past. You should keep away from them as much as possible.

    You should rely on ORM tools like Hibernate and that will obviate the need to write any stored procedures.

    Death to stored procs, I say.

    CAPTCHA: nimis


    You're new here, right?

    Where I work, we use a farm of SQL servers. Gawd save us from the nonesense that hits the server without any thought of parameterisation, indexing, or plan optimisation... i.e. all the stuff from the sooper-dooper GUI that hangs IIS and SQL a dozen times a day.

    Captcha "quibus" - to quibble about the silliest of things. Fancy THAT happening!
  • galgorah 2011-01-28 08:46
    CnC:
    I find stored procedures useful because so often in big companies the application guys aren't database oriented and thus make design decisions that fail to utilize the horsepower of a big database (see Exadata2). And a database developer using something like PL/SQL can leverage the power more effectively by hiding that complexity from the app developers.
    I'm a software development lead and an accidental SQL Server DBA at my current job. I would argue that for most developers a basic understanding of SQL and database design is a must. Obviously there are some exceptions such as in industries where skill sets tend to be more specialized (games). If a member of my team is weak or has no skill in this area, I will make it a point to help bring them up to speed. We also have a very close relationship with our Oracle DBA's and the BI team. Both of whom will offer advice.
  • Mike 2011-01-28 08:59
    Well, some girls do and some girls don't.

  • frits 2011-01-28 09:02
    eric76:
    anon:
    The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.
    I was hired at my first job after college because I had a beard.

    They had narrowed it down to two of us. Since everyone there had a beard, I had a beard, and the other applicant didn't, I got the job.


    That's a great point. think about how much better ZZ Top would have been if the drummer had a beard.
  • luis.espinal 2011-01-28 09:11
    Jim Howard:
    I worked in the UK about 15 years ago, so things might have changed, but then age discrimination was very legal and normal.

    Applicant age was prominently mentioned in almost every employment advertisement. You'd see something like 'Java programmer with five years experience, should be between 20 and 30 years of age'.

    Here in the United States people over 40 are a protected group, along with veterans, felons, and people descended from Spain. Oddly people of Portuguese descent are not a protected group.

    Go figure.


    Please provide links to legislature (state or federal) that states felons, people from Spain and people over 40 are to be treated as protected groups.

    kthxbye.
  • Nuno Milheiro 2011-01-28 09:11
    The real WTF is TDWTF accepts to publixh stories from the porn guy. Enough for me. I'm cuuting it with reading TDWTF
  • Phil 2011-01-28 09:15
    frits:
    eric76:
    anon:
    The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.
    I was hired at my first job after college because I had a beard.

    They had narrowed it down to two of us. Since everyone there had a beard, I had a beard, and the other applicant didn't, I got the job.


    That's a great point. think about how much better ZZ Top would have been if the drummer had a beard.


    His name is Frank Beard, which I think would lose it's funniness if he actually had a beard.
  • galgorah 2011-01-28 09:20
    Dirge:

    Ad-hoc SQL is never going to have the execution plan(s) pre-built on the server side, is it? If not, there's a performance hit right there.
    The execution plan is not actually prebuilt. SQL Server 2008 generates a Query Plan when the proc is compiled and stores it in the query cache. However Every concurrent execution of the procedure will generate an execution plan as well. Plus if the proc contains a lot of branching each run could produce a drastically different execution plan. So you could end up with multiple execution plans in the query cache for the same proc. Thats why you have the recompile option. It will tell SQL Server to NOT store a query plan in the cache.

    Addendum (2011-01-28 10:46):
    that first sentence should read: The execution plan is prebuilt.
  • Andrew Brehm 2011-01-28 09:29
    Ken B.:
    But atoms can be broken down into smaller components, making the term a misnomer.


    No. Atoms cannot be broken down into smaller components.

    We just made a mistake when we named atoms "atoms".
  • Billy Goat Gruff The Lesser 2011-01-28 09:34
    Andrew Brehm:
    Ken B.:
    But atoms can be broken down into smaller components, making the term a misnomer.


    No. Atoms cannot be broken down into smaller components.

    We just made a mistake when we named atoms "atoms".


    Darn. That Large Hadron Collider is a *complete* waste of time & money; my electron microscope is running on empty, and the atom bombs are all bang and no rads.

    Curse Quark and his pesky tricks (or was that Q in Star Trek?)
  • Warpedcow 2011-01-28 09:43
    anon:

    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.


    Whew, I'm glad I can still refuse to hire anyone who isn't a conservative Christian by claiming I don't like their necktie!

    Loopholes are the only good thing about bad laws.
  • frits 2011-01-28 09:45
    Jim Howard:
    Here in the United States people over 40 are a protected group, along with veterans, felons, and people descended from Spain. Oddly people of Portuguese descent are not a protected group.

    Go figure.


    That's because we Portuguese run the US through secret societies.

    Ever heard of the Knights of Columbus?
  • Design Pattern 2011-01-28 09:56
    Rob White:

    OK smart guy, what race am I?

    Formula One, obviously!
  • Design Pattern 2011-01-28 10:06
    Jaime:
    Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.

    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.

    Try that on INFORMIX.

    You will learn that there is no "if .. then .. else .." and there are no variables outside stored procedures.

    (I do not claim that INFORMIX is anything other than TRWTF. But some companies are still running installations).

    Besides that stored procedures allow to maintain fine-grained access control on the database server.

    With ad-hoc SQL a user either has update permission on the whole table or on nothing. Stored procedures allow to grant access based on rules implemented in the stored procedure.

    I know that your kind will re-implement access-control and maintenance of user permissions in the application server, because "Why use what we already have bought with the DBMS? You will be faster when you implement it yourself and finish the job in six weeks."
  • no2trolls 2011-01-28 10:28
    anon:

    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.


    Thanks for clarifying that every person in the world is protected by the exact same "employment discrimination laws" (presumably created by Mr. Obama - Nobel peace prize winner and leader of the free world)regardless of which country they live in and what their legal status is..
  • boog 2011-01-28 10:46
    Jaime:
    OK, so I could have used a better word like "disproven" instead of "falsifiable". Congratulations for winning the vocabulary war.
    Vocabulary war? No, my problem was not your choice of word, but rather the statement you were making: You said falsifiable claims were a bad thing. That's kind of a big deal in any serious discussion.

    But I'm glad we cleared it up.

    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.

    Jaime:
    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.
    Before I do, I see that someone else has already taken up your challenge; let's see your response to them first.
  • Darth Scrum 2011-01-28 10:46
    Some Wonk:
    Ken B.:
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"
    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!
    But atoms can be broken down into smaller components, making the term a misnomer. Perhaps we should start using "quarkic operation"[tm] instead?

    It's atoms all the way down!


    Loved the reference, thanks for the chuckle :)
  • no2trolls 2011-01-28 10:58
    The porn guy was a COMPLETE failure in that interview.

    "Tell me something interesting you have worked on" in an IT interview should be intepreted as "I would like to know whether you will be interested in the type of work and challenges which we will be giving you."

    Giving them a story about an unrelated job has absolutely no merit as a response to this question. He may as well have talked about unicorns.
  • Jaime 2011-01-28 11:21
    Drak:
    Jaime:
    boog:
    Jaime:
    One of the errors I see people defending stored procedures make all of the time is to make easily falsifiable claims.
    When did it become erroneous to make falsifiable claims? Why did no one tell me?

    Jaime:
    There are plenty of ways to tweak ad-hoc SQL to get within 0.01% of the performance of stored procedures, especially if the server isn't CPU-bound, which most aren't.
    Am I the only one who uses stored procedures for more than just SQL queries? I believe database views already cover that area.
    OK, so I could have used a better word like "disproven" instead of "falsifiable". Congratulations for winning the vocabulary war. Now back to SQL...

    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.

    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.


    CREATE PROCEDURE Something
    @intI AS INTEGER
    AS
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here, can't be arsed for this example. Obviously just adding 1 to a variable doesn't require recursion, but some things seem to be more easily programmed recursively.
    IF @intI < 600
    EXEC Something @intI
    END
    SqlCommand cmd = cn.CreateCommand();
    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here. Recursion is handy, but algorithms can often be written in a non-recursive manner.
    -- When recursion is actually desired, use a temporary procedure or implement this one bit of functionality as a stored procedure.
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();



    I'm not against stored procedures, I simply think they aren't the only solution, and the alternatives are often better.
  • Jaime 2011-01-28 11:24
    boog:
    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.
    I do. Do you realize that the entire procedural language is available outside of stored procedures in both MSSQL and Oracle?
  • Spoom 2011-01-28 11:42
    Isn't it usually illegal to ask for a photograph on a job application, what with anti-discrimination laws and all?
  • JohnFx 2011-01-28 12:12
    At first I didn't even catch the non-returnable photo good in that WTF. I was too distracted by the blatantly illegal request for the applicant's age. The photo seemed natural after the setup that they were eager to discriminate based on non-job related things.
  • luis.espinal 2011-01-28 12:31
    boog:
    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.

    Jaime:
    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.
    Before I do, I see that someone else has already taken up your challenge; let's see your response to them first.


    Indeed. Some people fail to grasp what Turing Completeness actually means. Barring an external failure on the back-end or a badly made nested relationship, a pure SQL SELECT/INSERT/UPDATE/DELETE statement operates on a finite set of rows. It is a (somewhat poor) implementation of an algebra on finite sets of tuples. It is a language for writing deciders, programs that always halt solely on their finite input. SQL can never have the same expressive power in a stored procedure language like PL/SQL (based on Ada) or T-SQL. No way, no how.
  • Jay 2011-01-28 12:34
    The Flaming Foobar:
    amischiefr:

    Actually these are the kinds of questions that work best. You get the person talking about a subject and let them either talk themselves into or out of a job.


    They work great if you are looking for a lecturer.

    If you are looking for a person capable of writing high-quality code, you should probably try to find out what kind of problem-solving skills they have and not what they have memorized from DB101.

    There is practically no difference between writing, say, a Perl script, and a stored procedure. Any experienced programmer will need one good example of a stored procedure, and maybe a list of dos and dont's, and they'll be writing there own in like 5 minutes.


    Possibly true, but if in an interview you leave out all questions about things that the candidate might be able to learn, well, that wouldn't leave much to ask about, would it? I mean, any candidate could potentially learn any required skills given sufficient time and effort.

    What do you expect a company to do in an interview if not ask the candidate about his exerience with tools and techniques that he will need to do the job? OF COURSE it would generally be foolish to reject a candidate for not having one particular skill, as long as he has most of what you need. But you have to ask about a variety of skills to find which ones he has and which ones he doesn't.
  • Jay 2011-01-28 12:34
    pjt33:
    backForMore:
    Don't bother posting without a non-returnable photograph.

    Does it have to be a photograph of me?


    No. We would prefer if you sent some of Liz's photos.
  • ??? 2011-01-28 12:41
    Jaime:
    Drak:
    Jaime:


    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.


    CREATE PROCEDURE Something
    @intI AS INTEGER
    AS
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here, can't be arsed for this example. Obviously just adding 1 to a variable doesn't require recursion, but some things seem to be more easily programmed recursively.
    IF @intI < 600
    EXEC Something @intI
    END
    SqlCommand cmd = cn.CreateCommand();
    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here. Recursion is handy, but algorithms can often be written in a non-recursive manner.
    -- When recursion is actually desired, use a temporary procedure or implement this one bit of functionality as a stored procedure.
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();



    I'm not against stored procedures, I simply think they aren't the only solution, and the alternatives are often better.


    That sure looks like:

    Jaime: 0, Drak: 1
  • Jay 2011-01-28 12:56
    Warpedcow:
    anon:

    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.


    Whew, I'm glad I can still refuse to hire anyone who isn't a conservative Christian by claiming I don't like their necktie!

    Loopholes are the only good thing about bad laws.


    Well, in real life you would end up in court and you would have to convince the judge or jury that you didn't hire him because you didn't like his tie, while he would try to convince them that you didn't hire him because he is a Buddhist or whatever.

    In real life, of course, it would be smarter to come up with a more plausible story, like you didn't hire him because he has no experience with Stored Procedures and you believe this to be a crucial job requirement.

    Actually proving what the employer was thinking in one particular case is pretty hard. This is why so many discrimination lawsuits bring in statistical evidence, like, 30% of the people in our city are Portugease, but only 5% of this company's employees are Portugease, therefore they must be discriminating.

    Of course many employers find this very frustrating because, no matter how much anti-discrimination activists may deny it, in real life there are many jobs that certain categories of people rarely apply for, so it's tough for an employer to meet these implied quotas. Like, relatively few cooks at Chinese restaurants are black people. Is this because Chinese restaurant owners discriminate against blacks? Or could it maybe be that not many blacks apply? Of course rap bands rarely hire Chinese people, so I guess the discrimination works both ways. Few Moslems are bartenders. Few auto mechanics are women. Few aerobics instructors are men. Etc etc. Most people accept that gender, culture, religion, and a host of other factors may influence a person's career choices. But anti-discrimination laws often refuse to recognize this and insist that if all bagpipe players are Scottish, this must be because you discriminated against everyone else. The statistics prove it.
  • Matt Westwood 2011-01-28 13:14
    Ron:
    Jim Howard:
    Here in the United States people over 40 are a protected group, along with veterans, felons, and people descended from Spain. Oddly people of Portuguese descent are not a protected group.

    Go figure.
    It's because we all know the Spaniards "need a little help" while the Ports are just as good as anyone else.

    There, see? Segregating people by some arbitrary group and saying "you can't discriminate against these people" is discrimination! And it perpetuates the idea that some people -- not individuals, but groups -- are weaker, and couldn't make it on their own.

    I have a dream... that someday people will not be judged for the color of their skin, but for the content of their character. Radical, I know.


    That's a silly idea, but then that's what you'd expect from a Ron.
  • Jaime 2011-01-28 13:20
    ???:
    Jaime:
    Drak:
    Jaime:


    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.


    CREATE PROCEDURE Something
    @intI AS INTEGER
    AS
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here, can't be arsed for this example. Obviously just adding 1 to a variable doesn't require recursion, but some things seem to be more easily programmed recursively.
    IF @intI < 600
    EXEC Something @intI
    END
    SqlCommand cmd = cn.CreateCommand();
    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here. Recursion is handy, but algorithms can often be written in a non-recursive manner.
    -- When recursion is actually desired, use a temporary procedure or implement this one bit of functionality as a stored procedure.
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();



    I'm not against stored procedures, I simply think they aren't the only solution, and the alternatives are often better.


    That sure looks like:

    Jaime: 0, Drak: 1
    OK, then rather than going the sane direction and state that ad-hoc SQL can do it, but I think it's not the best idea in this case, I'll show that it can be done.

    SqlCommand cmd = cn.CreateCommand();

    cmd.CommandText = @"

    CREATE PROC #payload(@i int OUTPUT)
    AS
    BEGIN
    SET @i = @i + 1
    END";

    cmd.ExecuteNonQuery();

    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    EXEC #payload @intI OUTPUT
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();

    cmd.CommandText = @"DROP PROC #payload";
    cmd.ExecuteNonQuery();
  • Matt Westwood 2011-01-28 13:22
    eric76:
    anon:
    The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.
    I was hired at my first job after college because I had a beard.

    They had narrowed it down to two of us. Since everyone there had a beard, I had a beard, and the other applicant didn't, I got the job.


    Yes, that technique always works, but you can only apply it when both interviewers are bearded. It got me a job when I was desperate for work once. After my first pay packet I could then afford a razor, by which time it was too late for the company that hired me to decide they'd made a mistake, it would have been too much hassle to readvertise the job.
  • Jaime 2011-01-28 13:25
    Jay:
    Warpedcow:
    anon:

    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.


    Whew, I'm glad I can still refuse to hire anyone who isn't a conservative Christian by claiming I don't like their necktie!

    Loopholes are the only good thing about bad laws.


    Well, in real life you would end up in court and you would have to convince the judge or jury that you didn't hire him because you didn't like his tie, while he would try to convince them that you didn't hire him because he is a Buddhist or whatever.

    In real life, of course, it would be smarter to come up with a more plausible story, like you didn't hire him because he has no experience with Stored Procedures and you believe this to be a crucial job requirement.

    Actually proving what the employer was thinking in one particular case is pretty hard. This is why so many discrimination lawsuits bring in statistical evidence, like, 30% of the people in our city are Portugease, but only 5% of this company's employees are Portugease, therefore they must be discriminating.

    Of course many employers find this very frustrating because, no matter how much anti-discrimination activists may deny it, in real life there are many jobs that certain categories of people rarely apply for, so it's tough for an employer to meet these implied quotas. Like, relatively few cooks at Chinese restaurants are black people. Is this because Chinese restaurant owners discriminate against blacks? Or could it maybe be that not many blacks apply? Of course rap bands rarely hire Chinese people, so I guess the discrimination works both ways. Few Moslems are bartenders. Few auto mechanics are women. Few aerobics instructors are men. Etc etc. Most people accept that gender, culture, religion, and a host of other factors may influence a person's career choices. But anti-discrimination laws often refuse to recognize this and insist that if all bagpipe players are Scottish, this must be because you discriminated against everyone else. The statistics prove it.
    But, if you simply show eveidence that you tried, you're off the hook. For example, if statistics show that the community is 30% black, but your IT department is only 5% black, but you placed employment ads in publications that had prodominantly black subscribership, then you are fine. Even if you get zero qualified applicants, your only obligation is to make a real effort to reach minority candidates.
  • Jaime 2011-01-28 13:28
    luis.espinal:
    boog:
    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.

    Jaime:
    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.
    Before I do, I see that someone else has already taken up your challenge; let's see your response to them first.


    Indeed. Some people fail to grasp what Turing Completeness actually means. Barring an external failure on the back-end or a badly made nested relationship, a pure SQL SELECT/INSERT/UPDATE/DELETE statement operates on a finite set of rows. It is a (somewhat poor) implementation of an algebra on finite sets of tuples. It is a language for writing deciders, programs that always halt solely on their finite input. SQL can never have the same expressive power in a stored procedure language like PL/SQL (based on Ada) or T-SQL. No way, no how.
    The only way this statement makes sense is if you believe that ad-hoc SQL has no control statements. That would be incorrect. Both T-SQL and PL/SQL can be run outside of procedures.
  • hoodaticus 2011-01-28 13:39
    no2trolls:
    anon:

    I'd say it's abundantly clear you've never read up on employment discrimination laws. The only things you can't legally discriminate based on are the so called "protected classes": race, color, religion, national origin, age, sex, familial status, sexual orientation, gender identity, disability or veteran status. You can not hire someone because you don't like the color of their tie if you so choose and it's totally legal.


    Thanks for clarifying that every person in the world is protected by the exact same "employment discrimination laws" (presumably created by Mr. Obama - Nobel peace prize winner and leader of the free world)regardless of which country they live in and what their legal status is..
    He can be forgiven for citing American law, since all the benighted, primitive barbarians outside this great nation basically sit around all day wallowing in their own feces.
  • Design Pattern 2011-01-28 13:51
    Jaime:
    luis.espinal:
    SQL can never have the same expressive power in a stored procedure language like PL/SQL (based on Ada) or T-SQL. No way, no how.
    The only way this statement makes sense is if you believe that ad-hoc SQL has no control statements. That would be incorrect. Both T-SQL and PL/SQL can be run outside of procedures.

    And if you would have read luis post less distracted, you would have noticed that he contrasted T-SQL with SQL.

    T-SQL actually is not SQL, it is an extension of SQL.
  • hoodaticus 2011-01-28 13:52
    Jaime:
    boog:
    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.
    I do. Do you realize that the entire procedural language is available outside of stored procedures in both MSSQL and Oracle?
    Who uses only one or the other anyway?

    I use dynamic SQL when the query is stupid simple, or when it's too dynamic to write a stored procedure for (such as when I have query parts being populated by visitors to my business object). I use Stored Procedures when the query is complex and can benefit from the compile-time checking that occurs in SSMS when I create the procedure.
  • Esa-Pekka 2011-01-28 14:03
    hoodaticus:

    He can be forgiven for citing American law, since all the benighted, primitive barbarians outside this great nation basically sit around all day wallowing in their own feces.


    Oikeasti, joka ei ole tehnyt jotain tällaista?
  • trwtf 2011-01-28 14:04
    Matt Westwood:

    Yes, that technique always works, but you can only apply it when both interviewers are bearded.


    I believe it's not illegal to require a picture of the interviewer when you're called in for an interview... stupid, maybe, but not illegal.
  • boog 2011-01-28 14:09
    Jaime:
    boog:
    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.
    I do. Do you realize that the entire procedural language is available outside of stored procedures in both MSSQL and Oracle?

    I do. So why would you need to tweak it? It was that comment that originally threw me off. It implies that the code would have to be different enough to need tweaking.

    Next time, just make your claim clear and concise: Since the same code can be executed inside or outside a stored procedure, stored procedures are not inherently faster. Period. Not once did I disagree with you on that point.
  • boog 2011-01-28 14:35
    hoodaticus:
    Who uses only one or the other anyway?
    Exactly.

    I love how so many people on this site take an all-or-nothing approach. They either use stored procedures for any access to the database whatsoever or they ditch them completely.

    Stored procedures are not for everything. If you're using them to reinvent standard RDBMS features, you're doing it wrong. Stored procedures are subroutines, plain and simple: encapsulated code, each performing a single, specific task. So if you have logic that appears in more than one place and it's not in a subroutine, you're doing it wrong too.
  • Mike 2011-01-28 15:25
    If he'd been out of the DB world for long enough that this is his first reaction to stored procedures, whether or not he misheard me, I don't want to be his gateway back into the DB world.
  • Nagesh Kukunoor 2011-01-28 15:40
    boog:
    hoodaticus:
    Who uses only one or the other anyway?
    Exactly.

    I love how so many people on this site take an all-or-nothing approach. They either use stored procedures for any access to the database whatsoever or they ditch them completely.

    Stored procedures are not for everything. If you're using them to reinvent standard RDBMS features, you're doing it wrong. Stored procedures are subroutines, plain and simple: encapsulated code, each performing a single, specific task. So if you have logic that appears in more than one place and it's not in a subroutine, you're doing it wrong too.


    In our multi-layered application, we rely on Hibernate to do all CRUD work. The business logic is kept in a remote service hosted on a Unix box. The front-end is browser based. I personally am not sold on stored procedures being useful. This approach allows us to change tiers or layers as we want. The DB is simply a data source only.
  • luis.espinal 2011-01-28 15:55
    Jaime:
    luis.espinal:

    Indeed. Some people fail to grasp what Turing Completeness actually means. Barring an external failure on the back-end or a badly made nested relationship, a pure SQL SELECT/INSERT/UPDATE/DELETE statement operates on a finite set of rows. It is a (somewhat poor) implementation of an algebra on finite sets of tuples. It is a language for writing deciders, programs that always halt solely on their finite input. SQL can never have the same expressive power in a stored procedure language like PL/SQL (based on Ada) or T-SQL. No way, no how.


    The only way this statement makes sense is if you believe that ad-hoc SQL has no control statements. That would be incorrect. Both T-SQL and PL/SQL can be run outside of procedures.


    I know that T-SQL and PL/SQL can run outside of procedures. I've never done it with T-SQL, but I've done it with PL/SQL. It's an old trick of the trade, with its valid uses (and many abuses).

    That does not make them SQL. SQL is SQL, a declarative language for writing deciders on finite input and with limited control structures for transactions and data definitions.

    The programming constructs, including control structures, found on T-SQL are not SQL. Furthermore, an Ada-like, module capable language like PL-SQL cannot qualify as SQL, either. How about a store procedure written in Java? Would that be magically be SQL just because?

    That you can piggy-bag a vendor-specific stored procedure written in a Turing complete language like PL/SQL through a SQL statement, that does not make the whole thing SQL, either.

    A database engine can receive an string encoding either a SQL statement, or a program construct written in a vendor's specific stored procedure language, or a combination of both (a combination ruled by a SQL standard from trampolining into a stored procedure call AND vendor specific syntax for doing so). And it can execute it if the construct if valid. But that doesn't turn whatever you put into that string into SQL.

    SQL is not defined as a capability to send a string to a possibly remote relational database engine and have it execute there.

    Let me give you an example: This would be akin to me pasing control to a a library written in C from Java via JNI and claim that the library itself is Java. By virtue of it be written in C, I can do things within the library that are impossible with Java. And if I don't preserve certain invariants, I can break the calling Java program. This is an example of crossing domain boundaries - from one trusted domain into an untrusted one, hoping that the untrusted one preserve certain invariants.

    Likewise, I can do things within a stored procedure that makes it impossible for a calling SQL statement to halt, to act as a decider. Again, crossing domain boundaries, from a declarative, set-oriented one (SQL) into one that is vendor specific and that has never been fully defined in SQL (because it is pretty much impractical if not impossible.)


    Now, if you are using the term "SQL" to refer to

    1. a vendor's implementation of SQL IN COMBINATION TO
    2. vendor's specific stored procedural programming languages IN COMBINATION TO
    3. the ability to declare an ad-hoc string containing a SQL statement trampolining into vendor specific procedural program language constructs IN COMBINATION TO
    4. the ability to send that ad-hoc string from a client to a database engine for execution

    then

    by YOUR (really, yours) definition of "SQL" you would be right in saying you can use SQL to implement anything that can be implemented in a stored procedure.

    The problem is that it is not the standard definition of SQL; that is not what people universally refer to as "SQL", either academically or in the real world. I've never seen anyone (in academia or industry) referring to vendor-specific stored procedure program language constructs when referring to (or as part of) SQL.

    If that's how you define and see SQL and that works well for you, that's great. Just understand then that people in general will disagree with you (or misunderstand you) because you are using "oranges" to describe "apples and oranges" (and the fruit salad made thereof) when everyone else is using "apples" and "oranges" (and "orange and apple fruit salad") in a manner that is commonly understood.

    Peace.
  • Jaime 2011-01-28 16:08
    luis.espinal:
    Jaime:
    luis.espinal:

    Indeed. Some people fail to grasp what Turing Completeness actually means. Barring an external failure on the back-end or a badly made nested relationship, a pure SQL SELECT/INSERT/UPDATE/DELETE statement operates on a finite set of rows. It is a (somewhat poor) implementation of an algebra on finite sets of tuples. It is a language for writing deciders, programs that always halt solely on their finite input. SQL can never have the same expressive power in a stored procedure language like PL/SQL (based on Ada) or T-SQL. No way, no how.


    The only way this statement makes sense is if you believe that ad-hoc SQL has no control statements. That would be incorrect. Both T-SQL and PL/SQL can be run outside of procedures.


    I know that T-SQL and PL/SQL can run outside of procedures. I've never done it with T-SQL, but I've done it with PL/SQL. It's an old trick of the trade, with its valid uses (and many abuses).

    That does not make them SQL. SQL is SQL, a declarative language for writing deciders on finite input and with limited control structures for transactions and data definitions.

    The programming constructs, including control structures, found on T-SQL are not SQL. Furthermore, an Ada-like, module capable language like PL-SQL can qualify as SQL, either. How about a store procedure written in Java? Would that be magically be SQL just because?

    That you can piggy-bag a vendor-specific stored procedure written in a Turing complete language like PL/SQL through a SQL statement, that does not make the whole thing SQL, either.

    A database engine can receive an string encoding either a SQL statement, or a program construct written in a vendor's specific stored procedure language, or a combination of both (a combination ruled by a SQL standard from trampolining into a stored procedure call AND vendor specific syntax for doing so). And it can execute it if the construct if valid. But that doesn't turn whatever you put into that string into SQL.

    Let me give you an example: This would be akin to me pasing control to a a library written in C from Java via JNI and claim that the library itself is Java. By virtue of it be written in C, I can do things within the library that are impossible with Java. And if I don't preserve certain invariants, I can break the calling Java program. This is an example of crossing domain boundaries - from one trusted domain into an untrusted one, hoping that the untrusted one preserve certain invariants.

    Likewise, I can do things within a stored procedure that makes it impossible for a calling SQL statement to halt, to act as a decider. Again, crossing domain boundaries, from a declarative, set-oriented one (SQL) into one that is vendor specific and that has never been fully defined in SQL (because it is pretty much impractical if not impossible.)


    Now, if you are using the term "SQL" to refer to

    1. a vendor's implementation of SQL IN COMBINATION TO
    2. vendor's specific stored procedural programming languages IN COMBINATION TO
    3. the ability to declare an ad-hoc string containing a SQL statement trampolining into vendor specific procedural program language constructs IN COMBINATION TO
    4. the ability to send that ad-hoc string from a client to a database engine for execution

    then

    by YOUR (really, yours) definition of "SQL" you would be right in saying you can use SQL to implement anything that can be implemented in a stored procedure.

    The problem is that it is not the standard definition of SQL; that is not what people universally refer to as "SQL", either academically or in the real world. I've never seen anyone (in academia or industry) referring to vendor-specific stored procedure program language constructs when referring to (or as part of) SQL.

    If that's how you define and see SQL and that works well for you, that's great. Just understand then that people in general will disagree with you (or misunderstand you) because you are using "oranges" to describe "apples and oranges" (and the fruit salad made thereof) when everyone else is using "apples" and "oranges" (and "orange and apple fruit salad") in a manner that is commonly understood.

    Peace.
    So this entire rant was about confusion of terminology when the context made it very clear that ad-hoc SQL was being used to mean "any blob of text sent to the database server" instead of "blob of text that meets the ANSI SQL specification"? Did you purposely ignore the context in order to launch the rant or did you miss it entirely?

    Regardless of my loose use of the term, my posts would have made no sense with the strict definition of SQL. Wouldn't it have been easier to start with a criticism of the terminology rather than attack the conclusions?

    This is the problem with any discussion of stored procedures. Those who believe that stored procedures are the only solution will do anything to avoid listening to the truth that they are only one of several technologies to accomplish the goal. I can build an application that is fast, manageable and secure both with or without stored procedures. I use them when they make sense and ignore them when they are counter-productive. There is absolutely no goal that can only be attained throug a stored procedure. I take all of these attempts to derail the conversation as an admission of defeat.
  • boog 2011-01-28 16:13
    Nagesh Kukunoor:
    In our multi-layered application, we rely on Hibernate to do all CRUD work. The business logic is kept in a remote service hosted on a Unix box. The front-end is browser based. I personally am not sold on stored procedures being useful. This approach allows us to change tiers or layers as we want. The DB is simply a data source only.

    If using the DB as a data source only and maintaining all data integrity on another layer works for you, that's fine. You may think your setup doesn't benefit from using stored procedures, but others' setups do.

    So you advised people to ditch stored procedures completely. You provided no evidence that your solution is better; you didn't even establish any form of measurement by which to compare the two solutions. That's why so many people jumped down your throat about it. "My experience tells me X is better than Y" is not a convincing argument. It is flamebait.
  • Jaime 2011-01-28 16:18
    boog:
    Jaime:
    boog:
    Jaime:
    Who ever said that ad-hoc SQL was limited to queries? Name one SQL statement (other than RETURN) that can be used in a stored procedure, but not in an ad-hoc batch.
    You do realize that stored procedures typically have their own procedural language, don't you? There is a lot more you can do in a stored procedure than just run SQL statements.
    I do. Do you realize that the entire procedural language is available outside of stored procedures in both MSSQL and Oracle?

    I do. So why would you need to tweak it? It was that comment that originally threw me off. It implies that the code would have to be different enough to need tweaking.

    Next time, just make your claim clear and concise: Since the same code can be executed inside or outside a stored procedure, stored procedures are not inherently faster. Period. Not once did I disagree with you on that point.
    So, if you agree with me, then why did you say "You do realize that stored procedures typically have their own procedural language, don't you?". Saying that stored procedures have their "own" procedural language implies that you are unaware that those language elements can be used outside of stored procedures, which would imply that you think that things like loops and conditionals are limited to stored procedures. That amounts to disagreeing with me since without loops and conditionals, ad-hoc batches would be at a significant disadvantage to stored procedures.
  • Jaime 2011-01-28 16:28
    boog:
    Nagesh Kukunoor:
    In our multi-layered application, we rely on Hibernate to do all CRUD work. The business logic is kept in a remote service hosted on a Unix box. The front-end is browser based. I personally am not sold on stored procedures being useful. This approach allows us to change tiers or layers as we want. The DB is simply a data source only.

    If using the DB as a data source only and maintaining all data integrity on another layer works for you, that's fine. You may think your setup doesn't benefit from using stored procedures, but others' setups do.

    So you advised people to ditch stored procedures completely. You provided no evidence that your solution is better; you didn't even establish any form of measurement by which to compare the two solutions. That's why so many people jumped down your throat about it. "My experience tells me X is better than Y" is not a convincing argument. It is flamebait.
    People jumped down his throat because stored procedures are a religious topic in which many people hold beliefs that haven't been true for twenty years. Even if Nagesh had presented complete and reasonable arguments, he would have been treated the same.

    BTW, I think he's wrong about a DB only being a data source. I also think that writing vendor agnostic SQL virtually gaurantees less than stellar results. But I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go. My biggest argument for moving as much logic as possible out of the physical data tier is that databases are hard to scale while middle tier servers are easy to scale.
  • boog 2011-01-28 16:39
    Jaime:
    So this entire rant was about confusion of terminology when the context made it very clear that ad-hoc SQL was being used to mean "any blob of text sent to the database server" instead of "blob of text that meets the ANSI SQL specification"?
    I wouldn't say the context made it very clear; several people (myself included) assumed you were referring to DML statements, and not the procedural language.

    Jaime:
    This is the problem with any discussion of stored procedures. Those who believe that stored procedures are the only solution will do anything to avoid listening to the truth blah blah soapbox blah...
    Sorry, you're breaking up. All I hear is a whining sound.

    Before I lost you it sounded like you were saying your opponents' collective belief is that stored procedures are the only solution. But it seems to me that few of the people with whom you've actually been arguing have made that case. In fact, luis.espinal and I have been arguing with you this whole time simply because of a misunderstanding over your terminology.

    I'm just saying...
  • boog 2011-01-28 16:45
    Jaime:
    So, if you agree with me, then why did you say "You do realize that stored procedures typically have their own procedural language, don't you?". Saying that stored procedures have their "own" procedural language implies that you are unaware that those language elements can be used outside of stored procedures, which would imply that you think that things like loops and conditionals are limited to stored procedures. That amounts to disagreeing with me since without loops and conditionals, ad-hoc batches would be at a significant disadvantage to stored procedures.

    Fair enough; poor choice of working on my part:
    boog:
    You do realize that stored procedures typically have their own use a procedural language, don't you?
    Better?

    Addendum (2011-01-28 16:52):
    *wording, not working
  • boog 2011-01-28 16:50
    Jaime:
    I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go.

    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
  • luis.espinal 2011-01-28 17:43
    Jaime:
    So this entire rant was about confusion of terminology when the context made it very clear that ad-hoc SQL was being used to mean "any blob of text sent to the database server" instead of "blob of text that meets the ANSI SQL specification"?


    Clear to you maybe.

    At the end of the day "ad-hoc" means something you can make on the fly. SQL means... well, SQL. And "ad-hoc SQL" means... well, a SQL statement created on the fly. And nobody, nobody uses SQL to mean either ANSI SQL (or vendor specific SQL) in addition and combination to vendor specific store procedure language constructs.


    The only thing unclear until now was the origin of your atypical usage of the term "SQL" and "ad-hoc SQL" and the confusion about whether that atypical usage is done 1) for a purpose unbeknown to us, 2) a new technical trend, 3) because of a posting accident (we all do that), or 4) you don't know what you are talking about.

    Even if it is clear that you are using SQL to mean "anything" including the kitchen sink, it is not clear why you (or anyone) would use such an obtuse definition in lieu of a definition that has universally been used for effective communication of what SQL is for the last 4 decades.

    That's why nobody understand what you are talking about, and why anybody (not just me) is ranting. It makes no sense and serves no useful or practical purpose beyond your need to redefine an industrial term to make your proposition satisfiable. That which you did is a WTF.


    Jaime:
    Did you purposely ignore the context in order to launch the rant or did you miss it entirely?


    The existence of a context does not imply its validity or usefulness. An invalid or illogical context does not warrant attention. You don't like that response from readers of your post, then build logically valid contexts. That's akin to building an improbably edge case to attack the validity of a general purpose solution to a particular problem. Gee, you win, here have a cookie.

    Jaime:
    Regardless of my loose use of the term,


    Not loose. Incorrect. Non-standard. Confusing. Without apparent useful communicating purpose.

    Jaime:
    my posts would have made no sense with the strict definition of SQL.


    Not just strict, but standard and universally accepted in technical discussions, ergo correct.

    Jaime:
    Wouldn't it have been easier to start with a criticism of the terminology



    Gee, I thought I did (see below)


    me:

    That does not make them SQL. SQL is SQL, a declarative language for writing deciders on finite input and with limited control structures for transactions and data definitions.

    ....

    The programming constructs, including control structures, found on T-SQL are not SQL. Furthermore, an Ada-like, module capable language like PL-SQL cannot qualify as SQL, either.

    ....

    That you can piggy-bag a vendor-specific stored procedure written in a Turing complete language like PL/SQL through a SQL statement, that does not make the whole thing SQL, either.

    ....
    A database engine can receive an string encoding either a SQL statement, or a program construct written in a vendor's specific stored procedure language, or a combination of both .... But that doesn't turn whatever you put into that string into SQL.



    Jaime:
    rather than attack the conclusions?


    Attacking a conclusion is perfectly valid when the terminology is unclear (and in your case obtuse, non-standard... and wrong when it comes to standards.) Not to mention that I did criticize your terminology (see above.)

    Jaime:
    This is the problem with any discussion of stored procedures.


    I'm sorry, but I never engaged in a discussion on the validity or invalidity of stored procedures as my original post was about ORMs making stored procedures obsolete and unnecessary. If I did engage in a discussion on the validity or invalidity of stored procedures point out the post where I did so.

    As it is, the discussion between you and me is about your continuous and extensive usage of the term "SQL" and "ad-hoc SQL" in a manner distinct from what has been typically been used for the last four decades.

    Jaime:
    Those who believe that stored procedures are the only solution will do anything to avoid listening to the truth that they are only one of several technologies to accomplish the goal.


    Nice strawman (possibly crossbred with an Ad hominen). I challenge you to quote me anywhere where I've said or stated that stored procedures are the only solution, in this thread or in any thread. I challenge you. If that statement is not being directed at me, then that statement is out of place with respect to the discussion we are having (your usage of the terms "SQL" and "ad-hoc SQL")... it would be again another statement out of context (or with an unclear/invalid/malicious/fallacious/superfluous context.)

    Jaime:
    I can build an application that is fast, manageable and secure both with or without stored procedures. I use them when they make sense and ignore them when they are counter-productive.


    That's a fine statement, so fine it would have brought me to tears of joy had it been the topic of discussion. It is not.

    It is a red herring. It is not what is being argued about, and it is not an argument that I've made any reference of (in pro or in con) in this specific discussion (or in this thread.)

    Jaime:
    There is absolutely no goal that can only be attained throug a stored procedure.


    Fine statement. Fine red herring. Certainly a fine oxymoron, a redundant statement of the obvious. Point to where I've made any argument for or against that in this thread to you or anyone and you'll win a fine kindergarten shinny star sticky for being such a good boyscout.

    Jaime:
    I take all of these attempts to derail the conversation as an admission of defeat.


    You have made a series of strawmen and red herrings thorough your reply, so to talk about derailments (and to weaselly imply that questions to the validity of your statements amount to derailments) feels a little bit like a black pot and a black kettle feverishly discussing about their shared ability to absorb all frequencies of light.

    Perhaps you might feel like redefining the statements in my reply as a "derailment" in the same way you redefined "SQL" and "ad-hoc SQL" mistakenly (or purposely or ignorantly, only know).

    And since the interpretation of such statements... I mean "derailments" can only be taken in a melodramatic way as an admission of defeat at your sole, solemn, imperious and infallible discretion and interpretation (however illogical that might be), who am I to argue against your glorious triumph?

    You have teh winx0r by last man standing. Congratulations.

  • NC 2011-01-28 18:02
    I actually worked in the Adult Entertainment Industry as a Web Developer for almost 3 years, it's on my resume. Every damn job i go to the people ask me "So i've never known anyone who worked in the porn industry." or "Tell me about the porn industry!!!". First time I went job hunting after that job, i got 9 offers out of 10 interviews I sent to.
  • Jaime 2011-01-28 19:14
    boog:
    Jaime:
    I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go.

    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.
  • Jaime 2011-01-28 19:28
    luis.espinal:
    ...stuff...
    Here is the problem with holding the term SQL as such a non-flexible term -- When on the client side, we have to submit text to the server. We have to call what we submit something. Ad-hoc stuff doesn't work. Ad-hoc T-SQL sounds stupid and is only accurate for Micosoft SQL Server. So we all call it ad-hoc SQL when we aren't calling a stored procedure. It's a common term that I hear used this way a lot and doesn't imply that the content is only SQL, but rather implies that the it is the text of batch that will be submitted to a database server. I'm sorry if that terminology threw you off, but it is real terminology. Jeff Atwood seems to agree with me. So does Frans Bouma. If you Google "ad-hoc SQL", most of the resulting pages that are specific enough to infer a definition don't limit it to DML.
  • boog 2011-01-28 20:01
    Jaime:
    boog:
    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.

    So... how many of those guys said that stored procedures are the only way to go? One? Maybe two?

    Wait, what were you trying to prove with the above comment?
  • Jaime 2011-01-28 20:34
    boog:
    Jaime:
    boog:
    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.

    So... how many of those guys said that stored procedures are the only way to go? One? Maybe two?

    Wait, what were you trying to prove with the above comment?
    So, let's stop talking to each other and go get 'em. As long as one person still believes any of the following I won't rest:

    1. Stored Procedures are generally faster.
    2. Stored Procedures protect from SQL Injection.
    3. Stored Procedures are the only viable way to organize all database access for an application.
    4. Stored Procedures make it easier to performance tune an application.
    5. Stored Procedures are the only way (or even the best way) to make it so database access bugs can be addressed without re-deploying client code.
    6. The security benefits of Stored Procedures can't be duplicated with less effort using a different technology.
    7. Stored Procedures are easier to maintain than other sensible alternatives.

    Every poster above seems to hold at least one of these beliefs.
  • hoodaticus 2011-01-28 21:02
    Esa-Pekka :
    hoodaticus:

    He can be forgiven for citing American law, since all the benighted, primitive barbarians outside this great nation basically sit around all day wallowing in their own feces.
    Oikeasti, joka ei ole tehnyt jotain tällaista?
    Or, I suppose, speaking in Feces.
  • hoodaticus 2011-01-28 21:13
    boog:
    Stored procedures are subroutines, plain and simple: encapsulated code, each performing a single, specific task. So if you have logic that appears in more than one place and it's not in a subroutine, you're doing it wrong too.
    I was going to mention that, but then I thought about my codebase and realized that I virtually never have the same type of query being run by more than one class, and when I do, it's in the queue for refactoring because those classes are all doing the same thing and should be merged.
  • hoodaticus 2011-01-28 21:36
    Jaime:
    luis.espinal:
    ...stuff...
    Here is the problem with holding the term SQL as such a non-flexible term -- When on the client side, we have to submit text to the server. We have to call what we submit something. Ad-hoc stuff doesn't work. Ad-hoc T-SQL sounds stupid and is only accurate for Micosoft SQL Server. So we all call it ad-hoc SQL when we aren't calling a stored procedure. It's a common term that I hear used this way a lot and doesn't imply that the content is only SQL, but rather implies that the it is the text of batch that will be submitted to a database server. I'm sorry if that terminology threw you off, but it is real terminology. Jeff Atwood seems to agree with me. So does Frans Bouma. If you Google "ad-hoc SQL", most of the resulting pages that are specific enough to infer a definition don't limit it to DML.
    Explaining the obvious gets tiresome at times, doesn't it?
  • luis.espinal 2011-01-28 22:26
    Jaime:
    boog:
    Jaime:
    boog:
    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.

    So... how many of those guys said that stored procedures are the only way to go? One? Maybe two?

    Wait, what were you trying to prove with the above comment?
    So, let's stop talking to each other and go get 'em. As long as one person still believes any of the following I won't rest:

    1. Stored Procedures are generally faster.
    2. Stored Procedures protect from SQL Injection.
    3. Stored Procedures are the only viable way to organize all database access for an application.
    4. Stored Procedures make it easier to performance tune an application.
    5. Stored Procedures are the only way (or even the best way) to make it so database access bugs can be addressed without re-deploying client code.
    6. The security benefits of Stored Procedures can't be duplicated with less effort using a different technology.
    7. Stored Procedures are easier to maintain than other sensible alternatives.

    Every poster above seems to hold at least one of these beliefs.


    For the second time in a row I'm asking you to quote the post I've made where I've stated any the beliefs that you just listed. I'm waiting.

    You listed a bunch of people who made those arguments. Having said you also mentioned a same veiled accusation when you replied to me (in the second to the last of my posts that you replied to.)

    Jaime:
    This is the problem with any discussion of stored procedures.

    Those who believe that stored procedures are the only solution will do anything to avoid listening to the truth that they are only one of several technologies to accomplish the goal.



    That was in your reply that you address to me, as a reply to a post I addressed to you. Explain to me what post I've made that states that which you are pointing at. I'm waiting.
  • luis.espinal 2011-01-28 22:46
    hoodaticus:
    Jaime:
    luis.espinal:
    ...stuff...
    Here is the problem with holding the term SQL as such a non-flexible term -- When on the client side, we have to submit text to the server. We have to call what we submit something. Ad-hoc stuff doesn't work. Ad-hoc T-SQL sounds stupid and is only accurate for Micosoft SQL Server. So we all call it ad-hoc SQL when we aren't calling a stored procedure. It's a common term that I hear used this way a lot and doesn't imply that the content is only SQL, but rather implies that the it is the text of batch that will be submitted to a database server. I'm sorry if that terminology threw you off, but it is real terminology. Jeff Atwood seems to agree with me. So does Frans Bouma. If you Google "ad-hoc SQL", most of the resulting pages that are specific enough to infer a definition don't limit it to DML.
    Explaining the obvious gets tiresome at times, doesn't it?


    If you call that explaining.

    As to Jamie:

    The link you point to Atwoods' post only discusses a balanced between ad-hoc SQL (which is not defined anywhere as you do) and stored procedures.

    Quote the text in Atwood's post where he defines ad-hoc sql as you did.

    Where does Bouma in his post defines ad-hoc sql as you did? All he does in his post is provide the same balanced view of using ad-hoc SQL (SQL that you can execute verbatin off to a remote database engine) vs stored procedures. No arguments there.

    I've not argued anything against Atwood's or Bouma's POV on the subject. It is not an argument I've made, nor one that is in contention.

    Doing a google on ad-hoc sql and linking and misquoting programming personalities is simply an appeal to authority (and a poorly made attempt at that.) Again, the ability to piggy-bag vendor-specific constructs that are not part of SQL in any liberal interpretation of the dialect does not make it SQL, the declarative language that goes by that name.

    You did not make you context clear at first. And you stuck by it as the argument went by without stopping until many posts later to explicitly define it. Only later you introduced the term ad-hoc SQL. And ad-hoc SQL in the general sense of the world, as applied to all RDBMS, not just MSSQL simply means what I told you before: SQL run ad-hoc.

    And people jumped on it because we don't know whether you use that liberal interpretation of what SQL is (the term you previously said was as powerful as any stored procedure language) because you made a mistake in typing or don't know what you are talking about.

    Nothing on that is predicated in your false, red-herring argument that we (whoever 'we' that is) believe stored procedures are the alpha and omega of it all.

    Couple that with your infantile "I take all of these attempts to derail the conversation as an admission of defeat" (on an argument of SP being supreme, something I never made), it paints a very silly picture.

    If you still don't get that, that's on you, not me or anybody else.
  • Jaime 2011-01-28 22:50
    luis.espinal:
    Jaime:
    boog:
    Jaime:
    boog:
    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.

    So... how many of those guys said that stored procedures are the only way to go? One? Maybe two?

    Wait, what were you trying to prove with the above comment?
    So, let's stop talking to each other and go get 'em. As long as one person still believes any of the following I won't rest:

    1. Stored Procedures are generally faster.
    2. Stored Procedures protect from SQL Injection.
    3. Stored Procedures are the only viable way to organize all database access for an application.
    4. Stored Procedures make it easier to performance tune an application.
    5. Stored Procedures are the only way (or even the best way) to make it so database access bugs can be addressed without re-deploying client code.
    6. The security benefits of Stored Procedures can't be duplicated with less effort using a different technology.
    7. Stored Procedures are easier to maintain than other sensible alternatives.

    Every poster above seems to hold at least one of these beliefs.


    For the second time in a row I'm asking you to quote the post I've made where I've stated any the beliefs that you just listed. I'm waiting.

    You listed a bunch of people who made those arguments. Having said you also mentioned a same veiled accusation when you replied to me (in the second to the last of my posts that you replied to.)

    Jaime:
    This is the problem with any discussion of stored procedures.

    Those who believe that stored procedures are the only solution will do anything to avoid listening to the truth that they are only one of several technologies to accomplish the goal.



    That was in your reply that you address to me, as a reply to a post I addressed to you. Explain to me what post I've made that states that which you are pointing at. I'm waiting.
    Is your name in that list? If I meant you, I would have listed you. The "Those who" in the response to you was addressed to the seven list above. If I meant you, I wouldn't have said "Those who". The only problem I have with you is that our exchanges have roots in differences that are trivial. I would rather help someone discover that the guy at work was wrong when he told them that SPs protect against SQL Injection than argue with you about whether SQL means ANSI SQL in the strict sense, or if it is a generic technology, of which T-SQL is a vendor specific implementation.

    You simply sidelined the conversation into SQL vs. T-SQL, a sideline based on a simple misunderstanding. Let it go. BTW, if you don't hold any of those seven beliefs, then you have the same opinion as me. Why call me out, but not call out any of those who have actual substantially differing opinions?
  • Jaime 2011-01-28 23:06
    luis.espinal:
    hoodaticus:
    Jaime:
    luis.espinal:
    ...stuff...
    Here is the problem with holding the term SQL as such a non-flexible term -- When on the client side, we have to submit text to the server. We have to call what we submit something. Ad-hoc stuff doesn't work. Ad-hoc T-SQL sounds stupid and is only accurate for Micosoft SQL Server. So we all call it ad-hoc SQL when we aren't calling a stored procedure. It's a common term that I hear used this way a lot and doesn't imply that the content is only SQL, but rather implies that the it is the text of batch that will be submitted to a database server. I'm sorry if that terminology threw you off, but it is real terminology. Jeff Atwood seems to agree with me. So does Frans Bouma. If you Google "ad-hoc SQL", most of the resulting pages that are specific enough to infer a definition don't limit it to DML.
    Explaining the obvious gets tiresome at times, doesn't it?


    If you call that explaining.

    As to Jamie:

    The link you point to Atwoods' post only discusses a balanced between ad-hoc SQL (which is not defined anywhere as you do) and stored procedures.

    Quote the text in Atwood's post where he defines ad-hoc sql as you did.

    Where does Bouma in his post defines ad-hoc sql as you did? All he does in his post is provide the same balanced view of using ad-hoc SQL (SQL that you can execute verbatin off to a remote database engine) vs stored procedures. No arguments there.

    I've not argued anything against Atwood's or Bouma's POV on the subject. It is not an argument I've made, nor one that is in contention.

    Doing a google on ad-hoc sql and linking and misquoting programming personalities is simply an appeal to authority (and a poorly made attempt at that.) Again, the ability to piggy-bag vendor-specific constructs that are not part of SQL in any liberal interpretation of the dialect does not make it SQL, the declarative language that goes by that name.

    You did not make you context clear at first. And you stuck by it as the argument went by without stopping until many posts later to explicitly define it. Only later you introduced the term ad-hoc SQL. And ad-hoc SQL in the general sense of the world, as applied to all RDBMS, not just MSSQL simply means what I told you before: SQL run ad-hoc.

    And people jumped on it because we don't know whether you use that liberal interpretation of what SQL is (the term you previously said was as powerful as any stored procedure language) because you made a mistake in typing or don't know what you are talking about.

    Nothing on that is predicated in your false, red-herring argument that we (whoever 'we' that is) believe stored procedures are the alpha and omega of it all.

    Couple that with your infantile "I take all of these attempts to derail the conversation as an admission of defeat" (on an argument of SP being supreme, something I never made), it paints a very silly picture.

    If you still don't get that, that's on you, not me or anybody else.
    Read the comments in both linked pages. In both cases, the concept of submitting a batch of statements comes up and neither author rejects the concept as not being ad-hoc SQL.

    Also, stop getting offended that my rants were in responses to your posts. We are conversing in public, not private. It is tiresome to break each thought into a separate response post, so I sometimes tack these little rants onto the end of specific responses. I do use language to attempt to clarify the audience, such as "Those who". In order to feel that comment is directed at you, you must first self-select as one of "Those who". Are you?

    I have had the stored procedure discussion many times and it always seems like I'm aiming at a moving target. That specific statement was an attempt to get the discussion back on focus. This whole SQL vs. T-SQL thing is like focussing on the bacteria on a flea on an angry lion. Drop it. We didn't connect, but it is resolved now.
  • Sudo 2011-01-29 03:23
    Paco:
    It's sad that people are such prudes. If it were me interviewing that guy would have moved to the top of the list.

    Why? Because his experience as a photographer in the adult entertainment industry shows he is obviously a good programmer?

    I admit, it's crazy to turn the guy down on that basis, but it would be just as crazy to hire him because of it.

    I think most of us would rather work with competent bores than incompetent "characters"...
  • SQLDave 2011-01-29 08:22
    The Corrector:
    goob:
    Ok. Let's review:

    1) Len gets job and goes to college.
    2) Len interviews for new job, putting past job on resume.
    3) Company blacklists Len based purely on the answer to a seemingly-benign interview question.
    3.1) Len gets sex change operation, becoming Liz.
    4) Liz gets a new job.
    5) Liz interviews candidate.
    6) Liz blacklists candidate based purely on the answer to a seemingly-benign interview question.

    FTFY


    FTFY
  • SQLDave 2011-01-29 08:32
    Bub:
    Should I keep my tale of college summers spent manually extracting bull semen quiet?

    Or just bring a bottle of hand-sanitizer along to offer them?

    Was "Bull" the nickname of your roommate?
  • Iain Collins 2011-01-29 09:54
    dolor:

    Your the reason why I have to work with incompitant numbskulls. Try boning up on your interview skills.

    Karma's a bitch.
  • Ilya Ehrenburg 2011-01-29 20:24
    Jaime:
    boog:
    Jaime:
    I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go.

    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.

    Umm, Jaime, please re-read the posts you linked. Most were pretty explicit that stored procedures are one way among others; superior for some tasks but not all. And will was even pretty critical of stored procedures.

    Altogether, in this altercation, you came off as the guy with the religious view that stored procedures are evil (yes, I know, you never said that, it's just the impression your tone generated) and the reality-distortion field.

    Calm down a little and when somebody calls you out on your wrong terminology, say "Oops, my bad" and don't claim to be the winner when they finally make it clear that their issue with you is terminological.

    Peace.
  • Farkisaurus 2011-01-30 02:56
    stibbons:
    together with a non-returnable photograph to careers@-------.com


    So what happens if your email bounces?


    Well, hopefully, the recipient will have arranged e-mail forwarding with the Post Office so that doesn't happen.

    CAPTCHA: validus: the sword used by a Roman validator.
  • Sylver 2011-01-30 04:16
    dpm:
    While I've never read up on actual discrimination laws, it sounds actionable to refuse to consider hiring someone because of a completely legal job in their past. That would be like me showing someone the door because he admitted to being "Barney" on television years ago. It _feels_ justified but it ain't ethical.


    Bull. When recruiting, you are trying to find someone who will be an asset and who will get along fine with the rest of the team. A previous job in the pornographic industry would tend to indicate fairly low moral standards, and bringing this experience in a recruitment interview for a programmer position demonstrate a lack of common sense.

    It's not relevant, and for *** sake's, if that was his most interesting job and his past programming jobs were boring to him, what is he doing applying for a job at a software company?

    So, if low moral standards and lack of common sense are not valid grounds for rejecting a candidate, what are?
  • Farkisaurus 2011-01-30 04:17
    Capt. Obvious:
    trwtf:
    Capt. Obvious:
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany. Ok, that's normally a very formal, decent photo as for a passport, but some people also send more "nice" photos to present themselves in a hopefully positive way. This is a funny issue that in USA people are fearing discrimination by giving away their photo on this occasion, normally it's us here in Europe who have bigger fears of privacy violations, see all these StreetView and Facebook troubles recently.

    Germany doesn't have a large group of visually distinctive people who are often discriminated against... at least not like the US does.



    Unless, of course, you count the Turks.

    At 3% of the population, I considered the Turks. But that's only 3%. It's not like the US with its substantial black and latino populations (12.5% and 10%). The US has a higher percentage Asian people (4.5%) and multiracial people than Germany does Turks. Hell, the US has more Native Americans than the Germany has Turks, in absolute numbers.

    It's hard to talk about Germany's racial uniformity without skating the Godwin line. However, looking at France, it's only slightly more diverse (with a 5.25% of the population coming from Northern Africa and 1.75% from the rest of Africa... although only about 3% of France is black.) Turks only make up 0.7% of the French population.


    That's because France was part of Germany when Germany was in the process of becoming more racially homogenous.
  • Kuba 2011-01-30 08:49
    boog:
    [...]
    Nagesh Kukunoor:
    ORM has pretty much obviated the need to write a stored procedure. Only old FUDDY DUDDY's are writing them.
    Well, I'm not an "old FUDDY DUDDY" and I write stored procedures. I guess I just proved you wrong. Generalizations suck, don't they?
    Troll feeding day it must be.
  • Luiz Felipe 2011-01-30 12:36
    M:
    I found stored procedures are very useful to getting performance back where Linq to SQL just dies on its arse.

    One example is searching a set of products based on name, code, manufacturer etc. These are all "OR" operations, building it in linq was painful and took a few seconds to execute. Writing it in a stored procedure reduced this to 60 odd milliseconds!

    So optimise where necessary I guess.



    I solved this with linq by creating the tree manually using the linq.expression namespace.
    Not so cool in contrast with using linq sintatic sugar, but it will do the job.
    And the sql are generated only to filters set istead of superduper non-optimizable convoluted logic expression.



  • Jaime 2011-01-30 14:46
    Ilya Ehrenburg:
    Jaime:
    boog:
    Jaime:
    I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go.

    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.
    Most?

    CnC
    Dirge
    BigJim
    sql guy
    M
    will
    Design Pattern

    Not spam, not spam, not spam.

    Umm, Jaime, please re-read the posts you linked. Most were pretty explicit that stored procedures are one way among others; superior for some tasks but not all. And will was even pretty critical of stored procedures.

    Altogether, in this altercation, you came off as the guy with the religious view that stored procedures are evil (yes, I know, you never said that, it's just the impression your tone generated) and the reality-distortion field.

    Calm down a little and when somebody calls you out on your wrong terminology, say "Oops, my bad" and don't claim to be the winner when they finally make it clear that their issue with you is terminological.

    Peace.
    I said "Oops, my bad" several times. However, my terminology errors didn't influence the outcome of the core discussion. All they did was lead into an aside that should have died quickly, but didn't. Also, if "ad-hoc SQL" isn't the proper terminology for a batch sent to a database server, then what is? It's not just my terminology that's imprecise, it's the entire industry. Heck, Microsoft trademarked the term "Microsoft SQL Server" for a product that wasn't ANSI SQL compliant for years after being named that.

    will's error was that he thinks not using stored procedures creates extra round-trips. That is false. I'm certain that this means that he will recommend stored procedures are the best answer to a category of problems where it is simply not true. This is why his post is included in the list. I admit that only one or two on the list are completely on the "always use procs" bandwagon, but that's still one or two. The others are recommending procs in specific situations where they have zero benefit. I'll bet 100 people who read this thread work in shops where not using stored procedures will get code rejected.

    Unfortunately, most of the bandwidth in this discussion has been spent on the definition of the acronym "SQL" (and in one case "falsifiable" vs "disproven"). I tried to get off it by admitting defeat several times, but it still won't go away. In truth, I don't really think I was wrong. SQL can be a specific term that is applied only to those topics addressed in ANSI SQL (SELECT/INSERT/UPDATE/DELETE), or it can mean database languages that have grown from it, like T-SQL or PL/SQL. It's hard to argue that Transact-SQL isn't a variant of SQL, given its name.

    As for my tone, I'm actually hoping it will cause someone to take up the challenge. I've specifically called out at least seven people who hold pretty widely held beliefs. Unfortunately, all I got out of it was a bunch of people who fundamentally agree with me nit-picking terminology.
  • Tore Sinding Bekkedal 2011-01-30 15:55
    Ken B.:
    too_many_usernames:
    Henning Makholm:
    too_many_usernames:
    We are a primarily embedded systems company, so one question on the test is: "What is an atomic operation?"
    Perhaps I'm ignorant, but what's the causal connection between embedded systems and atomic operations?
    I suppose I should have qualified "embedded" as "real-time embedded controls." Data incoherency is *not* your friend!
    But atoms can be broken down into smaller components, making the term a misnomer. Perhaps we should start using "quarkic operation"[tm] instead?


    "Atomic" in this context doesn't refer to the physical concept of atoms, but rather the name itself, given due to the same attribute as was once believed physical atoms posessed; "atomos" is Greek for "cannot be cut".
  • ik 2011-01-30 20:21
    Jaime:
    ???:
    Jaime:
    Drak:
    Jaime:


    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.


    CREATE PROCEDURE Something
    @intI AS INTEGER
    AS
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here, can't be arsed for this example. Obviously just adding 1 to a variable doesn't require recursion, but some things seem to be more easily programmed recursively.
    IF @intI < 600
    EXEC Something @intI
    END
    SqlCommand cmd = cn.CreateCommand();
    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here. Recursion is handy, but algorithms can often be written in a non-recursive manner.
    -- When recursion is actually desired, use a temporary procedure or implement this one bit of functionality as a stored procedure.
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();



    I'm not against stored procedures, I simply think they aren't the only solution, and the alternatives are often better.


    That sure looks like:

    Jaime: 0, Drak: 1
    OK, then rather than going the sane direction and state that ad-hoc SQL can do it, but I think it's not the best idea in this case, I'll show that it can be done.

    SqlCommand cmd = cn.CreateCommand();

    cmd.CommandText = @"

    CREATE PROC #payload(@i int OUTPUT)
    AS
    BEGIN
    SET @i = @i + 1
    END";

    cmd.ExecuteNonQuery();

    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    EXEC #payload @intI OUTPUT
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();

    cmd.CommandText = @"DROP PROC #payload";
    cmd.ExecuteNonQuery();


    So you are not against the "procedure" part, you are against the "stored" part. So everything's fine if you drop the procedure afterwards? Wow.
  • Jaime 2011-01-30 20:49
    ik:
    Jaime:
    ???:
    Jaime:
    Drak:
    Jaime:


    Let's try a little challenge... you post a stored procedure and I'll post ad-hoc SQL that runs nearly identically. Spoiler: I'm simply going to remove the CREATE PROC from your post, turn the arguments into batch variables and re-post it.


    CREATE PROCEDURE Something
    @intI AS INTEGER
    AS
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here, can't be arsed for this example. Obviously just adding 1 to a variable doesn't require recursion, but some things seem to be more easily programmed recursively.
    IF @intI < 600
    EXEC Something @intI
    END
    SqlCommand cmd = cn.CreateCommand();
    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    SET @intI = @intI + 1
    -- do someting actually useful here. Recursion is handy, but algorithms can often be written in a non-recursive manner.
    -- When recursion is actually desired, use a temporary procedure or implement this one bit of functionality as a stored procedure.
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();



    I'm not against stored procedures, I simply think they aren't the only solution, and the alternatives are often better.


    That sure looks like:

    Jaime: 0, Drak: 1
    OK, then rather than going the sane direction and state that ad-hoc SQL can do it, but I think it's not the best idea in this case, I'll show that it can be done.

    SqlCommand cmd = cn.CreateCommand();

    cmd.CommandText = @"

    CREATE PROC #payload(@i int OUTPUT)
    AS
    BEGIN
    SET @i = @i + 1
    END";

    cmd.ExecuteNonQuery();

    cmd.CommandText = @"

    WHILE @intI < 600
    BEGIN
    EXEC #payload @intI OUTPUT
    END";

    cmd.Parameters.AddWithValue("@intI", 6);
    cmd.ExecuteNonQuery();

    cmd.CommandText = @"DROP PROC #payload";
    cmd.ExecuteNonQuery();


    So you are not against the "procedure" part, you are against the "stored" part. So everything's fine if you drop the procedure afterwards? Wow.
    So, this is the back-and-forth game now? First I reply that this is one of those edge cases where stored procedures actually makes sense and I decline to give a full working example. Somebody calls it in favor of the other guy. So, I submit a working example to prove that it can be done, and now it's called against me for being a bad idea!!! I already said that. How could you possible read that post and think I'm against using a stored procedure for this one?

    This post was about "is it possible", not "is it a good idea".
  • chorlton 2011-01-31 07:57
    too_many_usernames:
    "What is an atomic operation?"

    We have in our archives the hand-written response: "it involves the nucleus of atoms."


    Similarly, when interviewing for a graduate trainee:

    Question
    "How would you describe polymorphism?"

    Answer (in a broad Scots accent)
    "Aw aye, that's when it kind ae like spreads oot aw ower the page like, eh?"

    It does sound like he might actually have seen The Enterprise Dependency but we were looking for something a bit more technical.
  • boog 2011-01-31 11:47
    Jaime:
    Unfortunately, most of the bandwidth in this discussion has been spent on the definition of the acronym "SQL" (and in one case "falsifiable" vs "disproven").

    About the "falsifiable" vs. "disproven" discussion:

    1. I was only taking a friendly jab at you (at the time) for implying that falsifiability was a bad thing. It was in no way previously an extensive debate as you seem to characterize it in the comment above.

    2. Non-falsifiable statements are a detriment to intelligent discussion; implying that the difference between "falsifiable" and "disproven" is trivial or even "nit-picking" demonstrates a real misunderstanding of proper argument on your part, and should have indicated to me early on that I'd better back out of the discussion altogether.

    I strongly urge you to read up on falsifiability and it's importance in scientific discussion and debate. I sincerely believe it could improve your arguing abilities, and maybe even help you to avoid some of these side arguments you frequently tend to be a part of.

    As for the discussion on SQL, I have already backed out; it isn't going anywhere, and I don't have time for it any more.
  • Nagesh 2011-01-31 12:35
    I started a discussion here

    Can I not start a discussion?
  • sql guy 2011-02-01 05:48
    Jaime:
    So, let's stop talking to each other and go get 'em. As long as one person still believes any of the following I won't rest:

    1. Stored Procedures are generally faster.

    In general they are similar in speed, assuming identical SQL statements, although caching of ad-hoc queries might not always be as good as for procedures. In practice though, queries usually grow more complex over time and optimization is better done on the database side by database experts.

    Another win for stored procedures is over things like views that have nested subqueries. Sometimes the internal optimiser can't pass a WHERE clause through to the inner query, so the view runs very slowly. With a stored procedure you can filter the inner query directly with a parameter which can massively speed things up.

    I assume you aren't against views as well?

    2. Stored Procedures protect from SQL Injection.

    As long as you don't have dynamic SQL in your procedures they should be immune to SQL injection. But then so will ad-hoc SQL as long as you use parameters and don't make the newbie mistake of building SQL strings by simply concatenating variables. But as a DBA do you want to put the security of your database at the mercy of application developers who might not understand SQL security issues so well?

    3. Stored Procedures are the only viable way to organize all database access for an application.

    Clearly it can be done in other ways, but I would argue they aren't as good. Encapsulation of your database (to borrow an OO term) is always a good idea.

    4. Stored Procedures make it easier to performance tune an application.

    This is very true in my experience. If you have a fixed set of ways to access the database you only have to go through them and check performance and indexing is all set up OK for them. If you have ad-hoc SQL statements hitting the server that are possibly changing over time without your knowledge, the only way to do it is to put on a SQL trace recording every query hitting the server (maybe over a certain time threshold) and trawl through them looking for problems.

    5. Stored Procedures are the only way (or even the best way) to make it so database access bugs can be addressed without re-deploying client code.

    This seems obvious - how would you fix a data access bug that was in client code without re-deploying it?

    6. The security benefits of Stored Procedures can't be duplicated with less effort using a different technology.

    Very true in my experience. Simply give EXEC permissions to the application user on a fixed set of stored procedures. Much easier than setting various SELECT, UPDATE, DELETE, INSERT permissions on hundreds of individual tables. Especially if the database schema is evolving over time.

    7. Stored Procedures are easier to maintain than other sensible alternatives.

    Again, true in my experience. Especially if you have two teams working together, one for database and one for front-end code. Decoupling your data access and your presentation front-end is a good idea, with a fixed and clearly defined interface of stored procedures between the two.
  • sql guy 2011-02-01 05:53
    boog:
    Jaime:
    I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go.

    Again, it's funny that most of the people with whom you've been arguing this whole time don't think stored procedures are the only way to go.

    I can't really think of a situation where you wouldn't want to use stored procedures for a front-end application.

    Possibly when your application has some kind of caching going on and needs to know when tables have changed content? I'm sure there are ways round that problem though.
  • badla 2011-02-01 20:45
    asdglkm al;kwe gakwle g
    badla@mail.md
  • itsmo 2011-02-07 06:08
    <>:
    jger:
    OldPeter:
    Well, it's fairly common to send photographs with a resume over here in Germany.


    It´s not about sending a non-returnable photograph at all but about sending a non-returnable photograph by email.

    Yor from Germany? Good, I have a question about my German automobile. I drive a Prius, and I heard that diesels get better gas mileage. So I filled it with diesel and now it's making funny noises. Can you help?

    FTFY
  • itsmo 2011-02-07 08:57
    Jaime:
    boog:
    Nagesh Kukunoor:
    In our multi-layered application, we rely on Hibernate to do all CRUD work. The business logic is kept in a remote service hosted on a Unix box. The front-end is browser based. I personally am not sold on stored procedures being useful. This approach allows us to change tiers or layers as we want. The DB is simply a data source only.

    If using the DB as a data source only and maintaining all data integrity on another layer works for you, that's fine. You may think your setup doesn't benefit from using stored procedures, but others' setups do.

    So you advised people to ditch stored procedures completely. You provided no evidence that your solution is better; you didn't even establish any form of measurement by which to compare the two solutions. That's why so many people jumped down your throat about it. "My experience tells me X is better than Y" is not a convincing argument. It is flamebait.
    People jumped down his throat because stored procedures are a religious topic in which many people hold beliefs that haven't been true for twenty years. Even if Nagesh had presented complete and reasonable arguments, he would have been treated the same.

    BTW, I think he's wrong about a DB only being a data source. I also think that writing vendor agnostic SQL virtually gaurantees less than stellar results. But I am more than happy to use his statements as a launching point to speak to those who think stored procedure are the only way to go. My biggest argument for moving as much logic as possible out of the physical data tier is that databases are hard to scale while middle tier servers are easy to scale.


    Nagesh=Troll (do not feed)
  • NonReturnable 2011-02-09 14:45
    pjt33:
    backForMore:
    Don't bother posting without a non-returnable photograph.

    Does it have to be a photograph of me?


    No. We will also accept a picture of a spider.
  • something 2011-02-15 04:36
    eric76:

    They had narrowed it down to two of us. Since everyone there had a beard, I had a beard, and the other applicant didn't, I got the job.


    And when they informed the other applicant, is that what they told her... ?
  • tgape 2011-02-18 19:48
    NC:
    I actually worked in the Adult Entertainment Industry as a Web Developer for almost 3 years, it's on my resume. Every damn job i go to the people ask me "So i've never known anyone who worked in the porn industry." or "Tell me about the porn industry!!!". First time I went job hunting after that job, i got 9 offers out of 10 interviews I sent to.


    Selection bias. By putting it on your resume, you only heard from people who either were not opposed to the porn industry or were so vehement in their opposition to the porn industry they called you just to rant at you. However, since I assume we're talking about businesses here, rather than churches, it's unlikely you got many of the latter.

    Also, your experience is completely relevant to IT: for three years, you worked in what is perceived by many to be the most demanding of all web developer jobs. (I've looked at a few porn sites - for a time I helped administer a friend's website on a server that also served some porn, and I got to see what crap code and crap security they can spew. So I'd agree that a porn server administrator is probably going to be reasonable to high quality. But a porn web developer may be stellar, or may be crap, and you can only tell by checking out the work product.)
  • tgape 2011-02-18 20:07
    Rob White:
    smxlong:

    When I mentioned that a person's race could often be guessed just by what their name is, they shrugged and said "Doesn't make any sense, but those are the rules."


    OK smart guy, what race am I?


    Dat's easy. You're human.

    See, the vast majority of people posting stuff on the Internet are either computers or humans. The computers usually do their best to not stand out, so they wouldn't ask others what race they are.

    The dogs and cats (and occasional monkey) posting aren't *nearly* as adept with English and typing{1} as you apparently are. The dwarves, elves, gnomes, sylphs, kzinti, nymphs, demons, mermaids, dragons, dopplegangers, tauren, kobolds, goblins, gremlins, xorn, hooloovoos, elementals, kraken, and pretty much all other fantasy creatures that you see online aren't really real - they're generally computers or people pretending to be fantasy creatures.

    {1} Not to imply that all humans or computers are adept with English. Most humans or computers who are active on the Internet are adept in at least one language, but it is not always English. And some seem to not be ept in any language.
  • Newbie 2011-02-24 14:09
    minkey:
    For the stored procedures one I think I would have made sure he heard me correctly. If he's been out of the DB world for a while his brain might have just gone to what he's used to first or he could have misheard. To dismiss someone that quickly because someone might be hard of hearing is kind of a dick move.



    I agree, I was in a similar situation, but luckily the interviewers re-phrased the sentence, and I caught on and changed my answer rather quickly. I got the job!!! Glad they didn't pull a dick move too, otherwise I may be in the same boat as him......
  • legutko@ztas.cz 2011-03-09 11:58
    jezisku, napis to tam vole
  • manchukuo 2012-01-09 17:24
    show pics of your phography pr0n career or is fake!!
  • Fergurg 2012-03-06 16:43
    And it gets better: the company CAN discriminate against a protected class as long as it can be shown that there is a valid reason for it. For example, I worked for a company years ago that would not hire Orthodox Jews or Seventh-Day Adventists because it was a job requirement to work Saturdays.
  • Sayer 2012-06-13 09:31
    Delicious pie is delicious.:
    dolor:
    The Article:

    My question was fairly straightforward: tell me about your experience with stored procedures.

    Interview fail. What kind of idiot question is this?


    Yeah, it really is a bit like asking an imperative programmer, "so, how about those user-defined functions?" Or like asking a truck driver, "so how do you feel about steering wheels?"


    I was once asked what my favorite Photoshop tool was.