• (cs) in reply to no
    Anonymous:
    Bullet:

    In spite of your sarcasm, and implied disresepect, I'll remain professional.  Let me explain more clearly.   Of course you can't access Google's DB.  But Google's developers (at some level of permissions) CAN access the DB.   There is no way to restrict raw SQL access to the DB except to restrict it to everyone.  Some internal development Manager/administrator can always give HIS developers access...  and then they can send raw SQL to the DB.  Only if ALL raw SQL access is inhibited can this be prevented.   Even then it can be a battle between Database Architectural Designers and developers, (like you), who don't understand, to keep those restrrictions in place.   But it's much, much easier to manage and enforce if the restriction is at the door to the database than if it's placed at the door to each and every application database entry point a web service. 

    On another note,  I respectfully suggest you skip the disrespectful sarcasm, it only detracts from your arguments.



    That is just a ridiculous argument to make. At some level, developers actually NEED access to SQL...to trouble shoot, debug, quick report, reverse engineer. That is just common sense.

    Now, again, no raw sql in the middle tier because ORMs and SQL is not dirty, just hire a decent developer and have a good DBA.

    I think I see the cause of the confusion - we're talking about SQL outside the database, and he thinks that means developers are outside the database. In that scenario, I guess SPs just sort of happen, which would indeed be scary. Actually, there are plenty of serverside developers about, and the vast majority of them can write database code. DBAs tend to specialize in operations and tuning, and generally don't  write production code. You would not want a DBA to be writing Hibernate files, if that's what he's proposing.

     

     

  • (cs) in reply to RyuO
    RyuO:
    Anonymous:

    That is just a ridiculous argument to make. At some level, developers actually NEED access to SQL...to trouble shoot, debug, quick report, reverse engineer. That is just common sense.

    Now, again, no raw sql in the middle tier because ORMs and SQL is not dirty, just hire a decent developer and have a good DBA.

    I think I see the cause of the confusion - we're talking about SQL outside the database, and he thinks that means developers are outside the database. In that scenario, I guess SPs just sort of happen, which would indeed be scary. Actually, there are plenty of serverside developers about, and the vast majority of them can write database code. DBAs tend to specialize in operations and tuning, and generally don't  write production code. You would not want a DBA to be writing Hibernate files, if that's what he's proposing.

    You might be right,  but if so, he's talking about these (even less qualified) developers (the ones coding all these Web services), having access rights to write SQL and send it to the DB...
    Also, although I hope this is not the case,  his statement about "Just lock out the developers from the db..."  might mean that he's one of those folks who are still passing actual user logins to connect to the DB, instead of creating application service accounts...  Otherwise, this statement makes no sense in the context of the issue we are debating... The access level of the developers, using their personal accounts, is immaterial to the architectural design of an application using a service account...  Best we assume he was just letting his enthusiasm pull him a bit off track...

  • (cs) in reply to Volmarias
    Volmarias:
    The sad thing is that he did

    param = sqlCmd.CreateParameter("int_01_in", adInteger, adParamInput, 8, Null) sqlCmd.Parameters.Append param

    param = sqlCmd.CreateParameter("int_02_in", adInteger, adParamInput, 8, Null) sqlCmd.Parameters.Append param

    ...

    When he should have done

    Dim val as String for(int i = 0; i < 50; i++) { val = i; if(i < 10)val = "0" + val; param = sqlCmd.createParameter("int_" & val & "_in",adInteger, adParamInput, 8, Null) sqlCmd.Parameters.Append param }

    (mind, my VB is a bit rusty, so this is probably not quite well written. But then, VB is a WTF in and of itself)

    Ah, code reuse. What a joyous concept!



    Erm... you could make this even more "Extensible" like so:

    Const intNumOfParameters 50
    Dim intCounter as Integer
    For intCounter = 1 To intNumOfParameters
       sqlCmd.Parameters.Append sqlCmd.createParameter("int_" & Right(String("0",Len(CStr(intNumOfParameters))) & intCounter,Len(CStr(intNumOfParameters))) & "_in", adInteger, adParamInput, 8, Null)
    Next

    That way, if he needs more parameters (even over 100) he can just change the const and the code itself will adjust, including putting in the right correct number of leading "0"'s

    Typed freehand, without the aid of intellisense (Or indeed, common sense, but you get the idea, I'm sure).

  • (cs) in reply to useless user
    Anonymous:

    I don't understand what is so hard to grasp about using dynamic SQL statements. Sure they are not compiled, but after all the hoops and crazy joins it sounds like you have to jump through, it just sounds easier to do a direct statement.

    Or does concatenating a string seems to non-|33+ for you?


    And the best thing is that the resulting code is very readable and almost never results in SQL injection vulnerabilities.

    NOT!

Leave a comment on “The Stored ÜberProcedure”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article