"Best Practices" Questions

  • If it wasn't January, I'd be wondering if this was a mis-scheduled April Fools joke. Seriously, whoever crafted those 'recommendations' should probably not be allowed anywhere near a database server,

    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
  • This so far is the scariest thread of the year. Complete and total lack of understanding by some arrogant "senior" team member. I would run away as quickly as possible.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Eugene Elutin (1/14/2015)


    ...modern boxes for SQL Server keeping also have LED screens and in-built heating element for hot-fixes...

    Heating elements! Is THAT why I've been having problems applying hot fixes?! And here I thought my hot glue gun was good enough. 😉

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Maybe it's just little old me, but does anyone else get the impression there are serious issues with the SQL Server instance itself (or instances as the case may be) or possibly the whole infrastructure?

    For example, I'm really having a hard time believing (vis-a-vis Gail's response) that simply connecting to production via SSMS is more likely to "bring down the server" than using RDP to accomplish the same thing or that using a Transaction can "destroy" a server.

    No doubt a lot of issues are self-inflicted due to these rules, but the "reasons" given for them seem a bit excessive under typical conditions.

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • lshanahan (1/15/2015)


    Maybe it's just little old me, but does anyone else get the impression there are serious issues with the SQL Server instance itself (or instances as the case may be) or possibly the whole infrastructure?

    For example, I'm really having a hard time believing (vis-a-vis Gail's response) that simply connecting to production via SSMS is more likely to "bring down the server" than using RDP to accomplish the same thing or that using a Transaction can "destroy" a server.

    No doubt a lot of issues are self-inflicted due to these rules, but the "reasons" given for them seem a bit excessive under typical conditions.

    I suspect that it's a question of unreasoning responses to problems. For example, someone opened a transaction, modified a substantial portion of a database and then didn't have a commit which lead to massive amounts of blocking. This appears to be a "destroyed" server since everything is stopped. The answer that they came up with, never use transactions. When, the answer should be, use transactions appropriately. Same thing with SSMS. I've seen people run queries from SSMS that hurt the server, and if lots of people are all running queries through SSMS that hurt the server, then it just makes sense, in a twisted way, to stop using SSMS, or least focus it through a single RDP point so only one bad query can run against the server at a time.

    It's just logical conclusions based on incomplete and incorrect information. It happens all the time.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • 5 - NEVER EVER EVER use SSMS's 'Edit Top 200 Rows' feature. "Using this locks the table when the window is left open".

    I've all but proven this one untrue, but I figured I'd ask anyway.

    The reason is wrong, but I agree with the rule. The edit can be a little buggy, I've seen it hang SSMS. Far better to write proper update statements.

    Plus you are bypassing any business rules that are not enforced in the database. "Backdooring" data can really foul up an application.

    Don Simpson



    I'm not sure about Heisenberg.

  • Thanks to OP for these valuable "Best Practices" that reminded me of my x-manager who was MBA and "nephew of our CEO". :angry:

Viewing 7 posts - 31 through 36 (of 36 total)

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