Post reply

Falling Over our Assumptions

  • April 7, 2009 at 10:08 pm

    #130454

    Comments posted to this topic are about the item Falling Over our Assumptions

    Best wishes,
    Phil Factor

  • April 7, 2009 at 10:41 pm

    #974004

    "Don't bother with that complicated outer join, just use the IN keyword"

  • April 7, 2009 at 10:42 pm

    #974005

    You know what you do when you Presume? You make a Pres out of U and Me.

    No, wait. That's not right ...

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.     [/font]    [font="Verdana"] "Performance is our middle name."[/font]

  • April 8, 2009 at 12:40 am

    #974028

    ".....but we've always done it that way"

    "No need for that where clause, we can filter the results in the GUI"

    Regards

    GermanDBA

    Regards,

    WilliamD

  • April 8, 2009 at 1:38 am

    #974051

    "If I just join these five views together I can select the three colums I want."

    which leads to

    "Why does this application run so slowly?"

    Never mind that they are complex, many tables, many columns selected, non-indexed views and the same tables are referenced multiple times and all it really needed was a simple select with a join on two or even three tables!

  • April 8, 2009 at 2:05 am

    #974063

    A few really insidious ones I regularly see are

    "....the user is always wrong"

    "I know my sphere of expertise inside out, so I must know yours better than you as well"

    "I will lose face or respect if I admit ignorance"

    Semper in excretia, suus solum profundum variat

  • April 8, 2009 at 2:33 am

    #974073

    Anyone come across one stored procedure, using a couple of cursors who in turn uses a few sp's that rely on several udf's so you end up with this huge tree? Where instead some temporary tables with the correct queries would just shorten it down to a very very small tree instead? I hate cursors that is used regularly in the code when in my mind cursors should only be used for easy use for something you want to do once. I find people who write cursors are not used to sql but keep the c/c#/java/etc programming style with them into the database.

  • April 8, 2009 at 2:40 am

    #974076

    "look it's just a place to store data..."

  • April 8, 2009 at 2:43 am

    #974079

    Two I can think of;

    "Dynamic SQL is always better than stored procedures".

    and;

    "Stored procedures are always better than dynamic SQL".

    Oh, and a bonus one that I've seen in practice is the assumption that primary- and foreign-keys are optional.

    Paul

  • April 8, 2009 at 2:50 am

    #974082

    Not sure I agree with "'Get something up and running. We can always tidy it up later' "

    You should always plan to have to tune/improve some parts of the system. When you are testing and let's say you have two testers at your disposal, there is no way you can simulate 2000 users, Deadlocks and such may only become apparent later.

  • April 8, 2009 at 2:50 am

    #974083

    Just an interesting observation. A couple of minutes ago, I got a little pop-up on my screen saying I'd received a new email. Unfortunately, the pop-up wasn't big enough to show the email's whole title, so did its usual truncation trick. Therefore I was being notified about

    SQLServerCentral - New Post - "RE: Falling Over our ***...

    I've never seen my computer demonstrate such an incisive wit before.

    Semper in excretia, suus solum profundum variat

  • April 8, 2009 at 2:53 am

    #974086

    paul.gregory (4/8/2009)

    Not sure I agree with "'Get something up and running. We can always tidy it up later' "

    You should always plan to have to tune/improve some parts of the system. When you are testing and let's say you have two testers at your disposal, there is no way you can simulate 2000 users, Deadlocks and such may only become apparent later.

    I have not done such tests myself but a consultant friend who is currently at another company was in a project where the testers had some programs at their disposal which they used to simulate a few thousand users doing things from different ip dresses so it's possible, what work it takes to get that going, I do not know.

  • April 8, 2009 at 3:02 am

    #974090

    And of course, users behave in exactly the same way as a piece of software trying to simulate what they do. I have also gone down this road before, but the only true test is when real people are doping stuff.

    And as my old grandaddy used to say, "Make something idiot proof, and they just go and make a better idiot."

  • April 8, 2009 at 3:06 am

    #974091

    In SSIS:

    "Always use Execute SQL task because the database engine is faster"

    "SSIS is slower than T-SQL"

    "Just use the script task/component"

    :crazy:

    Kindest Regards,

    Frank Bazan

  • April 8, 2009 at 3:16 am

    #974096

    My favourite must be the assumption that data volumes don't matter. Usually uncovered when I speak to a developer about the performance of their code. The frequent litany it 'but I tested it in dev and it was fast'.

    Yeah, fast on 10 rows. Production has 10 million rows. Not so fast there.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 15 posts - 1 through 15 (of 81 total)

You must be logged in to reply to this topic. Login to reply