Where Do You Go for Authoritative SQL Server Best Practices?

  • Comments posted to this topic are about the item Where Do You Go for Authoritative SQL Server Best Practices?

    Brad M. McGehee
    DBA

  • Before working with databases, I was an applications developer, so I have a solid understanding of general software engineering principles (particularly, the IEEE CS SWEBOK.) The general concepts apply across all software, whether it's desktop, web, mobile, or databases. This knowledge helps me determine if a “best practice” I find somewhere makes sense or if I should keep looking. It's also imperative to keep learning, to test new ideas before implementing them, and to readily change things that aren't working.

    It surprises me how many DBAs aren't familiar with even general SE concepts such as the software development life-cycle. I think all developers would benefit from spending some time working in a new area: DBAs to try app development, web developers to try desktop work, etc. But, I know that's wishful thinking for many people. I've been lucky in having the opportunity to do so.

    So in answer, I don't have a single oracle I consult. I prefer books over blogs because the tend to have more editors but that's not always reliable. Ultimately, I depend on my understanding of SE and my cross-training to help me triangulate good information from the cacophony of ideas and opinions available now.

    And, I always test something new. That's probably not even worth saying here, but you never know.

  • For books I use the Amazon ranking engine to help me to decide which is the "best" on the subject if I have decided to study something in real depth. The reviews are mostly well considered so one can usually be confident that something with ten 5*, a couple of 4* and a 1* is going to be a good book.

    For blogs I tend to follow what is happening in the online community as it quickly becomes apparent who knows what they are talking about. They are often the ones giving most to the community and will probably be speaking at PASS or SQLBits and generally putting themselves and their advice about. You all know who you are and thank you.

    Try following a few MVPs on Twitter and you will soon find an admirable network that you can turn to

    For direct questions I like the StackExchange way of doing things as the whole concept of reputation along with insisting that questions are clearly presented and answered seems to ensure a higher grade of answers than other sites (remember the bad old days of News Groups and the incoherent question?).

    Sometimes things are such a no brainer that I just do them (will I ever write a better index maintenance plan than Michelle Ufford - unlikely) other times serious research is needed before proceeding, as usual, it depends...

    And finally there is always books on-line, and thinking long, hard and deep.

  • There are some that would only accept Microsoft TechNet, Articles, White Papers. Some would venture to trusted sites and blogs. As for me, I look at what I consider my top 5 answers for a particular question, best practice and test it. In my opinion, anything you get from the internet you have to test to make sure that it fits and works in your environment. A good DBA is always compeled to evaluate what is the best for his/her environment.:-)

  • I pretty much use the same resources and in the order that you did when you wrote your book, Brad.

    For your final question, I NEVER take anything at face value for SQL Server. I always test for both the "happy path" and the "unhappy path". I trust no one in the outside world with my data or my servers and trust only a small group of people on the inside that I'm sure have the same beliefs and take the same care as I do.

    I'll also say that newbies have one tough time learning the right way to do things because of some very, very bad advice coming from "authoritative" and "well respected" individuals.

    For example, one of the supposedly best books of all time on SQL Server very plainly stated that you don't have to worry about estimating database sizes or how it will grow because, as of SQL Server 7, it would grow automatically. There was no mention of the 73 fragments (back then... it's worse now) that would be created at both the DB and OS levels for a DB to grow to just 1GB. There was no mention of how such fragmentation (especially for TempDB) could affect performance. Still, people will take such advice just because of who the author is.

    Another example is that I recently did some research on some hierarchical methods. The methods offered up on one blog were quite clever. Too clever in fact because the performance of the code was absolutely terrible. If the author did any performance testing, he sure did keep it a secret. The code didn't withstand even relatively small increases in scale. The really scary part is that the author is a well known "authority" and "highly respected" MVP and people will end up implementing his code just because of who he is.

    My advice to all newbies is to believe in nothing that you see, read, or hear. Try everything (it's why I include methods to create voluminous test tables in most of my articles). The only thing you can believe in is what you've actually done at least twice. As Sergiy says, "A Developer {or DBA} must not guess... a Developer MUST KNOW"! Make Books Online your friend (with the understanding that it can be a fickle friend) and understand that Google can be both your best friend and worst enemy. Buy a copy of SQL Server Developer's Edition, start at the beginning in Books Online, get involved with a forum like SQLServerCentral, and test everything. You'll soon become your own authority.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I guess with experience you just get used to trusting certain sites (like Brad's).

    As for coding, if you can't make sense of something that's been posted reasonably quickly, I suggest you move on to something that you can comprehend.

  • where do you go to find best practice advice?

    Peers , BOL , anywhere i can . Do I implement them ? not always , as you mentioned there is no one best practice that meets all needs.

    What books, websites, blogs, and other sources do you trust the most, and why?

    BOL has never let me down till date,

    SSC of course

    Pinal Daves blog is good.

    Experts Exchange

    I only trust the solution I get from each of these after I have tried them.

    I like the above but don't trust them

    Do you ever take this advice at face value, or do you always test it to ensure that it works well in your environment?

    I first try to understand the logic of any solution, I try them out as far as possible. However I am easy to please so i usually stop at the first solution that does well for my needs.

    Jayanth Kurup[/url]

  • paul s-306273 (6/27/2011)


    As for coding, if you can't make sense of something that's been posted reasonably quickly, I suggest you move on to something that you can comprehend.

    On the other hand, I've learned a whole lot of things by analyzing other people's code until I have an excellent understanding. High performance code isn't always easy to understand. For example, the absolute fastest method for resolving overlapping dates takes some reading and experimenting to fully understand. Once it's understood, though, it becomes "trusted" code and similar problems become child's play.

    Here's the link for the method I'm talking about.

    http://www.solidq.com/sqj/Pages/2011-March-Issue/Packing-Intervals.aspx

    Don't shortcut yourself by skipping things you don't understand. Learn to understand them. It's a part of the job. If it's not, you might be in the wrong job. 😉

    If you're not a member of that site, scroll all the way down for a link to become one. Like SQLServerCentral, they only want your email address and they don't sell or giveaway your email address unless you have the box checked that would allow them to do so.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I have yet to find any "one true solution" and there is no substitute for good judgement. Unfortunately good judgement comes from experience. And the experiences we learn the most from often come from bad judgement.

    I have a parable I'll pass on that I got from a mentor at my very first IT job getting out of college.

    "Make three envelopes"

    A new DBA arrives in a new job and is asked to come up with a rush report to determine what is the cause of all the problems with the current system. The old staff not being available because they have "been helped to find other employment opportunities". Ready to pull his hair out in panic and frustration he opens his desk to find only three plain white envelopes with the instructions "Open me first", "Open me second" and "Open me third."

    He opens the first envelope and in simple block letters it says "Blame all the problems on the outgoing service team. This will buy you six months." He talks to his supervisor and does just that. The supervisor is happy, it having confirmed that he was indeed correct in firing the previous, obviously incompetent, staff.

    Six months goes by and, while things have improved, management still wants more performance. At his wit's end the DBA remembers the other two envelopes and he rushes back to his office and opens the second. Inside, "Recommend significant hardware improvements. This should buy you at least another year." He goes back to his supervisor with the news and the company does indeed proceed to throw more hardware at the problem over a period of a few budget cycles.

    Now performance has significantly improved but the demand comes out for still more performance as the database isn't keeping up with the increased demands. The more it does the more that is demanded of it. By now the DBA knows that he has a magic lamp with a genie who has saved him before and he rushes back to his office and rips open the third envelope. Inside it reads...

    "Make three envelopes."

  • I just ask Jeff. 😀

    ______________________________________________________________________

    Personal Motto: Why push the envelope when you can just open it?

    If you follow the direction given HERE[/url] you'll likely increase the number and quality of responses you get to your question.

    Jason L. Selburg
  • MHilsher, I love your parable.

    Brad M. McGehee
    DBA

  • Jason Selburg (6/27/2011)


    I just ask Jeff. 😀

    :-P:blush:

    Thanks, Jason.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden suggested I might be in the wrong job..... I know I am.

    Paul.

    SAP ABAP developer.

    (and that's on Oracle).

  • Jeff Moden (6/26/2011)


    I pretty much use the same resources and in the order that you did when you wrote your book, Brad.

    For your final question, I NEVER take anything at face value for SQL Server.

    I tend to take the same path. Finding the information and then testing it is the best way to find the best practice and best implementation for your environment.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • I believe each topic needs its own authorative source. There is no one size fits all when it comes to SQL practice and/or development. Everywhere you look you find good arguments for doing things one way or another...........the best source is the one that allows a DBA to find the best practices for performance, stability and usability given his own setup. To ignore those conditions specific to that DBA's own business/data environment is asking for headaches and do overs.

    Any DBA will attest to this: the best list for anyone in our world is more about what NOT to do than best practices ;). Start that list with......take a backup even when you dont think you need one.

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

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