• (cs)

    DailyWtf, could you post this comment? No!

  • (cs)

    Cargo cult management much?

  • (cs)
    the managers are so conditioned to just hit approve that you could requisition a GAU-8 as a management training tool
    Hey! That's my line! Get off my meme!
  • gigaplex (unregistered)

    The first 5 paragraphs are redundant. You can skip them and still know what's going on.

  • (cs)

    Can we have the DBA's email address? Pleeeeaassse? I promise I won't send it to 4chan.

  • Willy (unregistered)

    Haha, just had this exact same conversation with our DBAs yesterday. Only upside: they responded to my request in 4 minutes, not 4 days...

  • Mike R. (unregistered)

    Hmmm... I'm wondering if that story came from my place of work. Seriously.

  • foxyshadis (unregistered)

    Those aren't DBAs. They're sysadmins (or BOFHs) giving themselves a fancy name. Good work on convining a company that a title means the opposite of how the rest of the world uses it, though.

  • Smug Unix User (unregistered)

    You could automate the "dba" out of procedure.

  • Simon Johnson (unregistered) in reply to gigaplex

    They may well be redundant but where is your sense of drama? Where's the build-up? Don't worry, what follows is a humorless version for robots like yourself

    1. Man A asks to create a database
    2. Man A and co-workers make database
    3. Man A asks Man B to check his work
    4. Man B is not responsible for checking his work

    Of if that's too much for you,

    1. Man A and co-works make database
    2. Man B is not responsible for checking his work

    That's enough to know whats going on right?

  • MrBester (unregistered)

    For those who don't know, a GAU-8 is the tankbusting nose gun on a Fairchild Thunderbolt (Warthog). It is codenamed "The Avenger" and shoots milk bottle (UK, a pint) sized rounds of depleted uranium at 3,600 rounds per minute. The recoil is enough to send a Warthog into a stall if you're flying a bit too casual.

  • RakerF1 (unregistered) in reply to MrBester
    MrBester:
    For those who don't know, a GAU-8 is the tankbusting nose gun on a Fairchild Thunderbolt (Warthog). It is codenamed "The Avenger" and shoots milk bottle (UK, a pint) sized rounds of depleted uranium at 3,600 rounds per minute. The recoil is enough to send a Warthog into a stall if you're flying a bit too casual.
    And Steve the Cynic keeps one in his back pocket as a tool of Darwinian selection...

    Captcha: feugiat - Oops, I feugiat that was Steve's meme!

  • Uhh (unregistered) in reply to Simon Johnson

    Department of X who contain the only people in company with titles "doer of X" that would require them (unlike any other title such as developers) to have any competency/skill/experience in doing X; when actually asked to do X say "ahhhh our department doesn't do any X at all, we only do some hardware maintenance".

    Thus it appears that the company doesn't have anyone capable of doing X, despite having a department for it. Isn't it a bit of WTF?

    Simon Johnson:
    They may well be redundant but where is your sense of drama? Where's the build-up? Don't worry, what follows is a humorless version for robots like yourself
    1. Man A asks to create a database
    2. Man A and co-workers make database
    3. Man A asks Man B to check his work
    4. Man B is not responsible for checking his work

    Of if that's too much for you,

    1. Man A and co-works make database
    2. Man B is not responsible for checking his work

    That's enough to know whats going on right?

  • Uhh (unregistered)

    It's like having a facilities maintenance department that say "uhh we only manage the cleaners, if you have faulty wiring or leaking plumbing, please handle that yourself".

  • golddog (unregistered)

    I've been fortunate enough to work with some quite competent DBAs. The current one, however:

    Once told me that using the "name" attribute instead of the unique id (int identity) to select records in a huge process was "just a matter of choice, because either one could change." Of course, only one of them has an administrative function built into the webapp.

    Outcome predictable.

  • The Voice of Experience (unregistered)

    The DBAs don't try to tell you how to design your application's data model, override your judgement on database interaction, deny your requests for storage or indices, and generally don't get in your way.

    I don't see a WTF here.

  • Rick (unregistered)

    This sounds similar to a previous job of mine. I used to work for a large (15k employees) department in the Canadian federal government, in a team that included the 6 DBAs for the Oracle cluster. They managed backups, disk space, versions and patches, users and permissions, partitions, replication, etc. All the stuff that's needed to keep it all working.

    What they didn't manage was the application-specific stuff, like tables, indexing, stored procedure and queries. That stuff was the responsibility of the lead developer or architect on each development team. If you needed help you could ask the DBAs, but it was best to talk to them early so you could book their time well in advance.

    To put a different spin on today's WTF, let me suggest that it might have happened this way:

    1. Dev manager puts a task in his schedule to get a DBA review. Dev manager doesn't actually tell the DBA team, just puts a note in to talk to them before project goes live.
    2. Dev team builds their app and database.
    3. Dev manager asks DBA for a review, and probably something like "please make it quick because we're done development and ready to go live."
    4. DBA says "No" because (a) it's not her primary responsibility, and (b) the other dev teams have booked all her available time for the next 2 months.
    5. Dev manager is pissed off that he can't get the DBA's time right away, and rather than admit he should have approached the DBA during the design phase or booked the time earlier, he complains about "risk" to management and then posts on TDWTF.

    I saw the above at least 2 dozen times in a 4 year period; I don't know for sure that today's WTF was the same, but I feel compelled to offer that opposing point of view.

  • (cs)

    I had a project to do once where I had to replace a complicated FORTRAN routine with an equivalent PL/SQL procedure. My PL/SQL skills are not great, so after I had finished it (and tested it to make sure it produced the same output) I passed it by the DBAs to vet it for efficiency etc. I got the almost immediate message back that as it was based on the functionality of the FORTRAN subroutine it was terrible and needed to be re-done. I spent some considerable time in looking at it to see whether it could be made more efficient, burning time I could have been spending on other things. Eventually, after a lot of frustration and complete inability to get any help with making it more efficient, I got a job somewhere else and handed in my notice. At this point the DBA inherited the project I was working on, and, hey presto, the PL/SQL process I had written was finally vetted properly by the head DBA who said that actually, in fact, it was a pretty good function and it could be released as it was, could I get on and do that? Sorry no, I said, this is my last day and I have other things to do.

  • anonymous (unregistered) in reply to Rick
    Rick:
    This sounds similar to a previous job of mine. I used to work for a large (15k employees) department in the Canadian federal government, in a team that included the 6 DBAs for the Oracle cluster. They managed backups, disk space, versions and patches, users and permissions, partitions, replication, etc. All the stuff that's needed to keep it all working.

    What they didn't manage was the application-specific stuff, like tables, indexing, stored procedure and queries. That stuff was the responsibility of the lead developer or architect on each development team. If you needed help you could ask the DBAs, but it was best to talk to them early so you could book their time well in advance.

    So they WEREN'T DBAs. For a second I believed you when you called them DBAs, but then you described what they actually do, and they're not.

  • deleted (unregistered) in reply to anonymous
    anonymous:
    Rick:
    This sounds similar to a previous job of mine. I used to work for a large (15k employees) department in the Canadian federal government, in a team that included the 6 DBAs for the Oracle cluster. They managed backups, disk space, versions and patches, users and permissions, partitions, replication, etc. All the stuff that's needed to keep it all working.

    What they didn't manage was the application-specific stuff, like tables, indexing, stored procedure and queries. That stuff was the responsibility of the lead developer or architect on each development team. If you needed help you could ask the DBAs, but it was best to talk to them early so you could book their time well in advance.

    So they WEREN'T DBAs. For a second I believed you when you called them DBAs, but then you described what they actually do, and they're not.

    There are dba's, and there are DBA's. The WTF is confusing one for the other.

  • (cs) in reply to MrBester
    MrBester:
    For those who don't know, a GAU-8 is the tankbusting nose gun on a Fairchild Thunderbolt (Warthog). It is codenamed "The Avenger" and shoots milk bottle (UK, a pint) sized rounds of depleted uranium at 3,600 rounds per minute. The recoil is enough to send a Warthog into a stall if you're flying a bit too casual.
    For those who don't know Google, you mean. :)

    It's also used on the Dutch "Goalkeeper" close-in weapon system. It basically shoots down everything it perceives as a threat to the naval vessel it's mounted on, completely autonomously. The Dutch developed this because they considered the American Phalanx system insufficient. It's pretty cool, as autonomous lethal weapons go.

  • Chubber (unregistered)
    What table-spaces are needed in a real environment? Do we need to create nicknames, and for what? What about temp space? Did we allocate enough? Are the partitions set up in the best way? What about the local/global indices? Did we set up roles correctly?

    None of those questions can be answered by someone who isn't intimate with the application logic used to access the databases and the profile of the data contained within. It sounds like the "DBA"s (a very broad title) are managing the server resources and services, not the details of the indexes.

    How will all of this migrate to the UAT environment? What about production?

    There is probably a form for that.

    We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

    Those sound like they are trying to get a data architect to "review" what should have been done up front.

  • Developer Dude (unregistered)

    Uhh yup, except for the automation (we have a lot of forms, but not automation), this is pretty much how it works at one of the largest corps in the world (where I work).

    Our "DBA"s are not Analysts, just DB Admins, they do not do any design, schema work or anything like that. They can barely get credentials/access to a DB setup correctly (I am still waiting for one "DBA" to do this correctly for one DB after 9 months - it will probably never be done).

    Welcome to life in the big city.

  • WorldClass (unregistered)

    Sounds like Bob doesn't know anything about databases. "No" seems appropriate.

  • (cs)

    "My mission is so secret, even I don't know what it is" -- Col. Flagg, MASH.

    Seems to me that the DBA's just sit in a sealed-off room somewhere, drinking their beers. When a request comes in for them to do some actual work, they just throw it back -- database contents are not their responsibility.

    When it comes time for their reviews, their position is "well, none of the servers crashed, so we're doing our jobs".

    Pretty sweet work, if you can get it.

  • (cs)

    BILL Hello, Peter. What's happening? Uh… we have sort of a problem here. Yeah. You apparently didn't put one of the new GAU-8s on your A-10 reports.

    PETER Oh, yeah. I'm sorry about that. I, I forgot.

    BILL MMMM..YEAH. YOU SEE, WE'RE PUTTING THE GAU-8s ON ALL A-10 REPORTS NOW BEFORE THEY GO OUT. DID YOU SEE THE MEMO ABOUT THIS?

    PETER Yeah. Yeah. Yeah. I've got the memo right here, but, uh, uh, I just forgot. But, uh, it's not shipping out until tomorrow, so there's no problem.

    BILL Yeah. If you could just go ahead and make sure you do that from now on, that will be great. And Uh, I'll go ahead and make sure you get another copy of that memo Mmmm, Ok?

    He walks away.

  • (cs) in reply to Severity One
    Severity One:
    MrBester:
    For those who don't know, a GAU-8 is the tankbusting nose gun on a Fairchild Thunderbolt (Warthog). It is codenamed "The Avenger" and shoots milk bottle (UK, a pint) sized rounds of depleted uranium at 3,600 rounds per minute. The recoil is enough to send a Warthog into a stall if you're flying a bit too casual.
    For those who don't know Google, you mean. :)

    It's also used on the Dutch "Goalkeeper" close-in weapon system. It basically shoots down everything it perceives as a threat to the naval vessel it's mounted on, completely autonomously. The Dutch developed this because they considered the American Phalanx system insufficient. It's pretty cool, as autonomous lethal weapons go.

    Hmmm, I think I saw the ground-based version of that. It says "Please put down your weapon. You have 20 seconds to comply..."

  • (cs) in reply to foxyshadis
    foxyshadis:
    Those aren't DBAs. They're sysadmins (or BOFHs) giving themselves a fancy name. ...

    This is demeaning to BOFHs. A true BOFH would give a lowly DBA a run for his/her money, and make life terrible for them.

    What these people are just paper shufflers making a 3 day delay line from request in to request out. No functionality here, please go away.

  • the beholder (unregistered) in reply to Rick
    WorldClass:
    Sounds like Bob doesn't know anything about databases. "No" seems appropriate.
    Chubber:
    Those sound like they are trying to get a data architect to "review" what should have been done up front.
    Rick:
    What they didn't manage was the application-specific stuff, like tables, indexing, stored procedure and queries. That stuff was the responsibility of the lead developer or architect on each development team. If you needed help you could ask the DBAs, but it was best to talk to them early so you could book their time well in advance.

    Uh-oh, we apparently have been invaded by an horde of DBAs tired of sitting on their thumbs wile their companies' devs do everything DB-related so they decided to spend time on tech forums to kill time.

    @Rick: I don't want the DBAs managing application specific stuff. I can handle it myself; in fact nobody knows what data MY system needs to store and retrieve from each table better than me. The submitter didn't ask them to do that. But table and index clustering, partitioning, data compression? That has DBA's job written all over it. Even situations like Matt Westwood's where he had to optimize a function sound like a joint effort dev+DBA is the way to go, i.e. the DBA should start moving his sorry ass.

    If the DBA can't do any of those things I mentioned I question how much he actually benefits the organization. That said, I've had the pleasure of working with a few GREAT DBAs in the past (even if that company was WTF-ridden elsewhere) and their job looked nothing like you described.

  • garaden (unregistered) in reply to Chubber
    Chubber:
    We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

    Those sound like they are trying to get a data architect to "review" what should have been done up front.

    Yeah, TRWTF is waiting four months to even start reviewing with a DBA. Of course, turns out he's waiting until the heat death of the universe, but oh well.

    Where I work all DDL must go through the data team, which makes sense to me, and definitely encourages people to bring them into the design process sooner rather than later. Waiting too long for review is a great way to have to make drastic changes late in your feature's development.

    Wish they wouldn't insist on using stored procs everywhere, though.

  • Donny (unregistered)

    Some countries run like this; policy over everything even common sense. I recall living in one (unnamed); here's a synopsis of our trials:

    1. We needed a bank account, but couldn't open one without a PPA (like a social security number).
    2. Go get a PPS? Can't get a PPS without proof of address, of which lease is not sufficient only bills/utilities.
    3. OK, get a utility bill? Can't get utilities switched on without credit facilities - credit card, store card, etc.
    4. Credit facilities? Needed a car, so good plan. Can't get credit facilities without a bank account OR drivers license.
    5. Drivers license? Good plan, just need a PPS number...

    And round-and-round the merry go round went, until we found a kindly bank official that let us open an account without a PPS number. That was fun...

    Bottom line/point of the story - there's a time for policy, and a time for common sense. Sadly, those that live by policy don't have a need for common sense, because it didn't get issues with their policy forms!

  • nothing to see here, move along (unregistered) in reply to Rick

    I agree.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    the managers are so conditioned to just hit approve that you could requisition a GAU-8 as a management training tool
    Hey! That's my line! Get off my meme!

    hehe, I thought you would approve

  • Mr. AHole DBA (unregistered) in reply to anonymous
    anonymous:
    Rick:
    This sounds similar to a previous job of mine. I used to work for a large (15k employees) department in the Canadian federal government, in a team that included the 6 DBAs for the Oracle cluster. They managed backups, disk space, versions and patches, users and permissions, partitions, replication, etc. All the stuff that's needed to keep it all working.

    What they didn't manage was the application-specific stuff, like tables, indexing, stored procedure and queries. That stuff was the responsibility of the lead developer or architect on each development team. If you needed help you could ask the DBAs, but it was best to talk to them early so you could book their time well in advance.

    So they WEREN'T DBAs. For a second I believed you when you called them DBAs, but then you described what they actually do, and they're not.

    No my dear friend anon, they actually are DBAs, they are not DB DEVS. There will come a day in your career that you move from the little shop or tiny silo'd department you work in and move to a real tech company. The separation of Operation DBAs vs Developer DBAs will become clear to you.

    I would go through the difference and give the plus/negatives to each, but it's already been done to death in every other story that has 'database' as the central theme, so just go look it up so you can learn about it.

  • Mr. AHole DBA (unregistered) in reply to garaden
    garaden:
    Chubber:
    We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

    Those sound like they are trying to get a data architect to "review" what should have been done up front.

    Yeah, TRWTF is waiting four months to even start reviewing with a DBA. Of course, turns out he's waiting until the heat death of the universe, but oh well.

    Where I work all DDL must go through the data team, which makes sense to me, and definitely encourages people to bring them into the design process sooner rather than later. Waiting too long for review is a great way to have to make drastic changes late in your feature's development.

    Wish they wouldn't insist on using stored procs everywhere, though.

    Sorry bud, but we really do need to insist on stored procs everywhere mainly for 2-3 reasons:

    1- Compliance. Almost any compliance doc out there will require you to reduce the exposure to the various types of SQL Injection attacks, and by proxy, almost all of them require you to use stored procs to do this.

    2-Performance, cache plan invalidation, excessive memory usage, nasty parameter sniffing and all other kinds of anomalies do show up when we don't use proper stored procedures. Add that with using it on a heap of a table instead of a clustered indexed one, and your chances of hitting a nasty performance issue skyrockets.

  • A Non. E. Mouse (unregistered)

    Although somewhat different, this story reminds me of the IT group at my current employer.

    We have a massive IT group compared to our operation/engineering staff (>40 IT employees including DBAs, SysAdmins, etc. vs. about 20 operations/engineering staff (only 5 of which actually handle the engineering roles)). We also have a lot of equipment for which we need >40 IT employees to manage.

    Recent new directive from head of IT: The IT group will be changing its focus in the upcoming weeks. Moving forward, our focus will solely be on maintaining our external web and email presence, tracking and procuring desktops/laptops, cellphones, and similar employee equipment, and help desk support for issues related to those. ALL OTHER SERVICES FOR WHICH IT HAS PREVIOUSLY BEEN RESPONSIBLE WILL NOW BELONG TO THE OPERATIONS AND ENGINEERING GROUP. The Operations Engineering team will be responsible for all IT activities in the production and development environments.

    I'm trying to figure out why then they need >40 employees (and currently requisitioning more, even though our operations and engineering group is in a hiring freeze).

  • kupfernigk (unregistered)

    At the other end of the scale:

    I once submitted a database creation script to the DBA at [UK insurance company]. The first comment on the first line read "Please review this script and flag anything that needs to be amended to suit your environment..."

    What I got was a phone call at 5p.m. a few days later from an irate DBA who informed me that my database creation script was the most unprofessional thing he had ever seen, it violated various company norms, that he was convinced that I was unqualified to write SQL, and that he was going to forward my name to the CIO and get him to instruct my company to remove me from the project immediately. I had tried to destroy his database server by writing a script that would, in his words, blow out his hard drives.

    I suggested that he might also want to complain to my professional body, and had he read the sentence at the top about reviewing the script? There was a sudden silence at the other end of the line, then he hung up.

    It turned out that the "DBA" himself wasn't qualified and created databases using SQL Studio. He hadn't actually come across automated database creation scripts before. But, most interesting, my sin was this: I had turned on logging. As you do. This guy had never enabled it, and was very proud of how he had been able to keep down the disc space used by company databases. Now he had an SQL Server installation that was too small to handle database logging for existing or new databases.Rather than admit his mistake, he had told the CIO that logging was a very bad idea. And he had then, without reading it, started to run a script which created a database and reserved space for the database and the log file. And it had failed, because there wasn't enough room on his disk cluster.

  • not an anon (unregistered) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    garaden:
    Chubber:
    We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

    Those sound like they are trying to get a data architect to "review" what should have been done up front.

    Yeah, TRWTF is waiting four months to even start reviewing with a DBA. Of course, turns out he's waiting until the heat death of the universe, but oh well.

    Where I work all DDL must go through the data team, which makes sense to me, and definitely encourages people to bring them into the design process sooner rather than later. Waiting too long for review is a great way to have to make drastic changes late in your feature's development.

    Wish they wouldn't insist on using stored procs everywhere, though.

    Sorry bud, but we really do need to insist on stored procs everywhere mainly for 2-3 reasons:

    1- Compliance. Almost any compliance doc out there will require you to reduce the exposure to the various types of SQL Injection attacks, and by proxy, almost all of them require you to use stored procs to do this.

    2-Performance, cache plan invalidation, excessive memory usage, nasty parameter sniffing and all other kinds of anomalies do show up when we don't use proper stored procedures. Add that with using it on a heap of a table instead of a clustered indexed one, and your chances of hitting a nasty performance issue skyrockets.

    Stored procedures have nothing to do with such things, sadly. It's quite possible to leave your rump bare to SQLi inside a sproc (I had to deal with a case recently where I had to generate dynamic SQL w/o bind params in a sproc due to dynamic table names shivers; at least I don't have to worry about them coming directly from user input), and it's also quite possible to write clean, safe, performant SQL in a database that doesn't even have stored procedures, simply by using bind params in your embedded SQL. Perhaps you should spend a weekend or two with SQLite to refresh yourself on the basics?

    CAPTCHA: decet - Any decet DBA will know bind params vs stored procs.

  • Mr. AHole DBA (unregistered) in reply to not an anon
    not an anon:
    Mr. AHole DBA:
    garaden:
    Chubber:
    We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

    Those sound like they are trying to get a data architect to "review" what should have been done up front.

    Yeah, TRWTF is waiting four months to even start reviewing with a DBA. Of course, turns out he's waiting until the heat death of the universe, but oh well.

    Where I work all DDL must go through the data team, which makes sense to me, and definitely encourages people to bring them into the design process sooner rather than later. Waiting too long for review is a great way to have to make drastic changes late in your feature's development.

    Wish they wouldn't insist on using stored procs everywhere, though.

    Sorry bud, but we really do need to insist on stored procs everywhere mainly for 2-3 reasons:

    1- Compliance. Almost any compliance doc out there will require you to reduce the exposure to the various types of SQL Injection attacks, and by proxy, almost all of them require you to use stored procs to do this.

    2-Performance, cache plan invalidation, excessive memory usage, nasty parameter sniffing and all other kinds of anomalies do show up when we don't use proper stored procedures. Add that with using it on a heap of a table instead of a clustered indexed one, and your chances of hitting a nasty performance issue skyrockets.

    Stored procedures have nothing to do with such things, sadly. It's quite possible to leave your rump bare to SQLi inside a sproc (I had to deal with a case recently where I had to generate dynamic SQL w/o bind params in a sproc due to dynamic table names shivers; at least I don't have to worry about them coming directly from user input), and it's also quite possible to write clean, safe, performant SQL in a database that doesn't even have stored procedures, simply by using bind params in your embedded SQL. Perhaps you should spend a weekend or two with SQLite to refresh yourself on the basics?

    CAPTCHA: decet - Any decet DBA will know bind params vs stored procs.

    Really cute attempt to talk like a DBA but it failed.

    Like it or not the reality of the situation is as I stated: Security compliance almost always requires you to use stored procedures, and their driver for that is security. Go pull up a list of sec requirements for 'at rest data management and access' to see for yourself.

    When you have to talk to business owners, C level execs, auditors, etc. you will see that like it or not, they will insist on it. Period. End of story. If you attempt to go around it the red tape needed to explain it, and find an auditor that cares is not worth it. BUT Hey it's your environment, YOU get to do what YOU want to do. Just don't come near my machines with that attitude.

    Sure some developer experienced enough could work around the proper steps of the solution, but why? Why pay someone to go 'around' an issue that the engines are optimzied for? So what if it can be done, should it be done? Answer is rarely yes, and even in cases like LinQ the justification is rare.

    Sure some idiot could still expose himself to sql injection attacks even in a sproc, but again, why? Why would you ever, ever hire that person? Blocking several kinds of SQL injection attacks by using proper paramaterized stored procedures puts you at such a huge advantage that I don't know why it would ever be advocated against, nevermind the compiled plans performance and memory usage; but I wouldn't expect a developer to care about that.

  • (cs) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    Sure some idiot could still expose himself to sql injection attacks even in a sproc, but again, why? Why would you ever, ever hire that person? Blocking several kinds of SQL injection attacks by using proper paramaterized stored procedures puts you at such a huge advantage that I don't know why it would ever be advocated against, nevermind the compiled plans performance and memory usage; but I wouldn't expect a developer to care about that.

    "But.....but.....I read a blog post about how it's bad!"

    The funny thing is that you guys are drawing different conclusions from pretty much the same arguments.

    (And, for what it's worth, I agree with you.)

  • Jim (unregistered) in reply to Donny
    Donny:
    Some countries run like this; policy over everything even common sense. I recall living in one (unnamed); here's a synopsis of our trials: 1) We needed a bank account, but couldn't open one without a PPA (like a social security number). 2) Go get a PPS? Can't get a PPS without proof of address, of which lease is not sufficient only bills/utilities. 3) OK, get a utility bill? Can't get utilities switched on without credit facilities - credit card, store card, etc. 4) Credit facilities? Needed a car, so good plan. Can't get credit facilities without a bank account OR drivers license. 5) Drivers license? Good plan, just need a PPS number...

    And round-and-round the merry go round went, until we found a kindly bank official that let us open an account without a PPS number. That was fun...

    Bottom line/point of the story - there's a time for policy, and a time for common sense. Sadly, those that live by policy don't have a need for common sense, because it didn't get issues with their policy forms!

    Process is like Scientific Theory. It defines how things should/would behave in the perfect world (or in a vaccuum if you like). Of course, we don't live in a vaccuum, nonetheless we see that our Scientific Theories still hold roughly (like we sort of write in an error margin because we're not in a vaccuum) to what we theorise.

    Process defines the "ideal world" way things should go, but it is the SPIRIT of the law that is important, not the LETTER (or as you put it, sometimes common sense must prevail). Yes, we accept that in a perfect world we could use your perfect processes for everything, however time constraints, urgent (or unexpected) issues, and a raft of other reasons might mean that we approximate the process rather than arbitrarily follow it to the letter....

  • jugis (unregistered) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    Blocking several kinds of SQL injection attacks by using proper paramaterized stored procedures puts you at such a huge advantage that I don't know why it would ever be advocated against
    So what's wrong with using proper parametrised queries that block SQL injection attacks in exactly the same way? (Except for "my shitty DMBS doesn't have them", but even MySQL does so that would be surprising.)
    Mr. AHole DBA:
    nevermind the compiled plans performance and memory usage; but I wouldn't expect a developer to care about that.
    Again, that depends on the DBMS. In a reasonable one, a prepared statement supplied by the client will be compiled in exactly the same way as statement executed from inside a stored procedure. But I strongly suspect that you're not talking about a DBMS that I'd consider remotely reasonable.
  • Frist (unregistered) in reply to Mr. AHole DBA
    Mr. AHole DBA:
    not an anon:
    Mr. AHole DBA:
    garaden:
    Chubber:
    We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

    Those sound like they are trying to get a data architect to "review" what should have been done up front.

    Yeah, TRWTF is waiting four months to even start reviewing with a DBA. Of course, turns out he's waiting until the heat death of the universe, but oh well.

    Where I work all DDL must go through the data team, which makes sense to me, and definitely encourages people to bring them into the design process sooner rather than later. Waiting too long for review is a great way to have to make drastic changes late in your feature's development.

    Wish they wouldn't insist on using stored procs everywhere, though.

    Sorry bud, but we really do need to insist on stored procs everywhere mainly for 2-3 reasons:

    1- Compliance. Almost any compliance doc out there will require you to reduce the exposure to the various types of SQL Injection attacks, and by proxy, almost all of them require you to use stored procs to do this.

    2-Performance, cache plan invalidation, excessive memory usage, nasty parameter sniffing and all other kinds of anomalies do show up when we don't use proper stored procedures. Add that with using it on a heap of a table instead of a clustered indexed one, and your chances of hitting a nasty performance issue skyrockets.

    Stored procedures have nothing to do with such things, sadly. It's quite possible to leave your rump bare to SQLi inside a sproc (I had to deal with a case recently where I had to generate dynamic SQL w/o bind params in a sproc due to dynamic table names shivers; at least I don't have to worry about them coming directly from user input), and it's also quite possible to write clean, safe, performant SQL in a database that doesn't even have stored procedures, simply by using bind params in your embedded SQL. Perhaps you should spend a weekend or two with SQLite to refresh yourself on the basics?

    CAPTCHA: decet - Any decet DBA will know bind params vs stored procs.

    Really cute attempt to talk like a DBA but it failed.

    Like it or not the reality of the situation is as I stated: Security compliance almost always requires you to use stored procedures, and their driver for that is security. Go pull up a list of sec requirements for 'at rest data management and access' to see for yourself.

    When you have to talk to business owners, C level execs, auditors, etc. you will see that like it or not, they will insist on it. Period. End of story. If you attempt to go around it the red tape needed to explain it, and find an auditor that cares is not worth it. BUT Hey it's your environment, YOU get to do what YOU want to do. Just don't come near my machines with that attitude.

    Sure some developer experienced enough could work around the proper steps of the solution, but why? Why pay someone to go 'around' an issue that the engines are optimzied for? So what if it can be done, should it be done? Answer is rarely yes, and even in cases like LinQ the justification is rare.

    Sure some idiot could still expose himself to sql injection attacks even in a sproc, but again, why? Why would you ever, ever hire that person? Blocking several kinds of SQL injection attacks by using proper paramaterized stored procedures puts you at such a huge advantage that I don't know why it would ever be advocated against, nevermind the compiled plans performance and memory usage; but I wouldn't expect a developer to care about that.

    This has got to be a troll.

  • (cs) in reply to Donny
    Donny:
    Bottom line/point of the story - there's a time for policy, and a time for common sense. Sadly, those that live by policy don't have a need for common sense, because it didn't get issues with their policy forms!

    The problem is, your story is not having the right paperwork to open a bank account is a time for policy. Said bank officer opened a loophole for money laundering and possibly fake driver's licenses. The policy should have an out, but it's frustratingly easier to avoid blame by not worrying about things like that and letting "common sense" people screw things up then open a hole that a politician or bureaucrat could be blamed for letting someone walk through.

  • (cs) in reply to foxyshadis
    foxyshadis:
    Those aren't DBAs. They're sysadmins (or BOFHs) giving themselves a fancy name. Good work on convining a company that a title means the opposite of how the rest of the world uses it, though.
    I've seen companies where the word "backend" referred to the front end...
  • (cs) in reply to Watson
    Watson:
    foxyshadis:
    Those aren't DBAs. They're sysadmins (or BOFHs) giving themselves a fancy name. Good work on convining a company that a title means the opposite of how the rest of the world uses it, though.
    I've seen companies where the word "backend" referred to the front end...
    I once worked for a company where "big" was a noun, and "66" was a verb.
  • (cs) in reply to cellocgw
    cellocgw:
    Severity One:
    MrBester:
    For those who don't know, a GAU-8 is the tankbusting nose gun on a Fairchild Thunderbolt (Warthog). It is codenamed "The Avenger" and shoots milk bottle (UK, a pint) sized rounds of depleted uranium at 3,600 rounds per minute. The recoil is enough to send a Warthog into a stall if you're flying a bit too casual.
    For those who don't know Google, you mean. :)

    It's also used on the Dutch "Goalkeeper" close-in weapon system. It basically shoots down everything it perceives as a threat to the naval vessel it's mounted on, completely autonomously. The Dutch developed this because they considered the American Phalanx system insufficient. It's pretty cool, as autonomous lethal weapons go.

    Hmmm, I think I saw the ground-based version of that. It says "Please put down your weapon. You have 20 seconds to comply..."
    At the risk of earning a "whoosh"(*), I'd just like to point out that a naval CIWS doesn't have 20 seconds available to give to an incoming missile. And yes, the Phalanx is a bit weedy, seeing as how it fires 20mm rounds, not the Goalkeeper's 30mm.

    The theory of operation of a CIWS is that you have a high-speed radar that scans for threats, and when you see one, you crank the gun around and open up. The weapon needs a high rate of fire to be able to put as many rounds as possible into the missile before it is too late, and even then there is a strong possibility that the (remains of the) missile will still hit the ship and punch a hole in it. Modern warships don't have armoured belts protecting their innards, so knocking big holes in them isn't actually very hard, if you can get past their defences.

    (*) Yes, I recognise the reference.

  • n/a (unregistered) in reply to jugis
    jugis:
    Mr. AHole DBA:
    Blocking several kinds of SQL injection attacks by using proper paramaterized stored procedures puts you at such a huge advantage that I don't know why it would ever be advocated against
    So what's wrong with using proper parametrised queries that block SQL injection attacks in exactly the same way? (Except for "my shitty DMBS doesn't have them", but even MySQL does so that would be surprising.)
    Mr. AHole DBA:
    nevermind the compiled plans performance and memory usage; but I wouldn't expect a developer to care about that.
    Again, that depends on the DBMS. In a reasonable one, a prepared statement supplied by the client will be compiled in exactly the same way as statement executed from inside a stored procedure. But I strongly suspect that you're not talking about a DBMS that I'd consider remotely reasonable.

    You both are forgetting at least one thing: granularity of access. No need to grant privileges for multiple scattered tables/objects/schemas (and don't say "views", because sometimes you have to modify your data and the complexity of managing those roles can rise very fast). Just one priviledge to execute, basically. Less space for human error and loopholes; and we don't really have to check very much about each client calling the sproc, because its purpose is so limited. I won't even mention "what if the DB schema has to be slightly changed (for performance, f.i.), while providing the same data".

  • Marlus (unregistered) in reply to Severity One
    Severity One:
    It's also used on the Dutch "Goalkeeper" close-in weapon system. It basically shoots down everything it perceives as a threat to the naval vessel it's mounted on, completely autonomously. The Dutch developed this because they considered the American Phalanx system insufficient. It's pretty cool, as autonomous lethal weapons go.

    Are there lots of vacancies for Dutch navy pilots by any chance?

    Would you really feel happy bringing your plane/helicopter into land while looking down the barrel of one of these things?

  • not an anon (unregistered) in reply to n/a
    n/a:
    jugis:
    Mr. AHole DBA:
    Blocking several kinds of SQL injection attacks by using proper paramaterized stored procedures puts you at such a huge advantage that I don't know why it would ever be advocated against
    So what's wrong with using proper parametrised queries that block SQL injection attacks in exactly the same way? (Except for "my shitty DMBS doesn't have them", but even MySQL does so that would be surprising.)
    Mr. AHole DBA:
    nevermind the compiled plans performance and memory usage; but I wouldn't expect a developer to care about that.
    Again, that depends on the DBMS. In a reasonable one, a prepared statement supplied by the client will be compiled in exactly the same way as statement executed from inside a stored procedure. But I strongly suspect that you're not talking about a DBMS that I'd consider remotely reasonable.

    You both are forgetting at least one thing: granularity of access. No need to grant privileges for multiple scattered tables/objects/schemas (and don't say "views", because sometimes you have to modify your data and the complexity of managing those roles can rise very fast). Just one priviledge to execute, basically. Less space for human error and loopholes; and we don't really have to check very much about each client calling the sproc, because its purpose is so limited. I won't even mention "what if the DB schema has to be slightly changed (for performance, f.i.), while providing the same data".

    What we need is a way to propagate stored procedure changes automatically with their matching code changes! Then again, at that level of schema management, wouldn't your DB schema already match what the app expects it to be anyway?

    CAPTCHA: saluto - I saluto anyone who has automatic stored procedure deployment built into their code deployment process.

Leave a comment on “Just Roll With It”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article