• (cs)

    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 (unregistered)
    together with a non-returnable photograph to [email protected]

    So what happens if your email bounces?

  • Nagesh Kukunoor (unregistered) in reply to hoodaticus
    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 (unregistered) in reply to hoodaticus
    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 (unregistered) in reply to Nagesh Kukunoor
    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.

  • (cs) in reply to Nagesh Kukunoor
    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 (unregistered) in reply to dpm

    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 (unregistered)

    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 (unregistered) in reply to minkey
    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 (unregistered) in reply to Clumsy Kid
    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 (unregistered) in reply to goob
    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 (unregistered) in reply to luis.espinal
    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.

  • (cs) in reply to too_many_usernames
    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 (unregistered) in reply to Chris
    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 (unregistered) in reply to OldPeter
    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?

  • (cs) in reply to Nagesh Kukunoor
    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 (unregistered) in reply to amischiefr
    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 (unregistered)

    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.

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

  • (cs)

    Discrimination because someone is a former porn photographer? Lame.

    It's not like they used to be a lawyer or something.

  • (cs) in reply to frits
    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.
  • (cs) in reply to boog
    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 (unregistered) in reply to The Flaming Foobar
    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 (unregistered) in reply to shadowman
    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 (unregistered) in reply to Leader of the Troll Army
    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 (unregistered) in reply to The Flaming Foobar
    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.

  • (cs) in reply to Matthew
    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 (unregistered) in reply to Henning Makholm
    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 (unregistered) in reply to Ken B.
    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 (unregistered) in reply to dolor
    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 (unregistered) in reply to Tim G
    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 (unregistered) in reply to TW
    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

  • (cs) in reply to trwtf
    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.
  • (cs) in reply to luis.espinal
    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 (unregistered) in reply to trwtf
    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 (unregistered) in reply to Tim G
    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".

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

  • (cs) in reply to Jaime
    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 (unregistered) in reply to luis.espinal

    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".

  • (cs) in reply to Delicious pie is delicious.
    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 (unregistered)

    Re: Shadows in a Vacuum.

    Dark in the Vacuum

  • (cs) in reply to Jaime
    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 (unregistered) in reply to OldPeter
    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 (unregistered) in reply to stibbons
    stibbons:
    together with a non-returnable photograph to [email protected]

    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 (unregistered) in reply to Capt. Obvious
    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.
  • (cs) in reply to History Agent
    History Agent:
    Capt. Obvious:
    Germany doesn't have a large group of visually distinctive people who are often discriminated against...
    ...anymore.

    FTFY

  • trwtf (unregistered) in reply to Capt. Obvious
    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 (unregistered) in reply to frits
    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 (unregistered) in reply to MichaelWojcik
    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 (unregistered)

    The non-returnable picture is probably just a cut & paste that didn't get fully updated from the days when they handled paper resumes.

Leave a comment on “Stored Procedures, The Porn Guy, and Non-returnable Email”

Log In or post as a guest

Replying to comment #:

« Return to Article