Page 1 of 2 12 LastLast
Results 1 to 15 of 20
  1. #1
    Join Date
    Jan 2003
    Location
    Nottinghamshire, UK
    Posts
    364

    Unanswered: TSQL 2008 Microsoft Coding Best Practice Guidelines

    Hi All

    I've been searching around and cannot seem to find any MSoft recommended Standard TSQL Coding Best Practices , stuff like formatting, not using SELECT * Bla, Bla, Bla.......

    Most companys I seem to work at seem to be in a constant state of customising their own (re-inventing wheels) with endless purist conversations etc.

    Does anyone know if there is an Industry Standard (Preff By MSoft) that we can use, if nothing else just to cut short the endless arguments & say, This is what MSoft recommend, This is what this Co uses, if your code varys from this please be ready to defend the exception to the rule.

    Obviously we're aware that in many cases it's horses for courses and Cart'e Blanche statements like DO NOT USE TEMPORY TABLES are not good.

    Any pointers appreciated

    GW
    "Everything should be made as simple as possible, but not simpler." - Albert Einstein
    "Everything should be made as complex as possible, so I look Cleverer." - Application Developer

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    We are the recognized international authorities on SQL coding and formatting best standards (except R937...). Post your code on here and invite the wolves to tear it apart, fighting over the placement of commas in enumerated lists, use of white space, natural vs surrogate keys, etc., like a pack of hyenas fighting over the last bit of marrow from a bone.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    oh, that's harsh, man

    you're off my christmas card list
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  4. #4
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,799
    Provided Answers: 11
    I think you will find there are no really solid rules for SQL development, because (as with most coding) everything comes with a tradeoff. Your best bet is to set guidelines, and have some sort of review process/board/person to judge cases when someone wants to step outside those guidelines.

  5. #5
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Code like me, and you'll be fine
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  6. #6
    Join Date
    Jan 2003
    Location
    Nottinghamshire, UK
    Posts
    364
    LOL, OK Guys, Thanks anyway

    I suppose we will just carry on as is .

    GW
    "Everything should be made as simple as possible, but not simpler." - Albert Einstein
    "Everything should be made as complex as possible, so I look Cleverer." - Application Developer

  7. #7
    Join Date
    Nov 2004
    Posts
    1,427
    Provided Answers: 4
    A colleague told me about a NATO document that specifies a set of database standards (mostly naming conventions). I'm not sure if this is the document, but it may be. I just Googled it, haven't read it yet.

    While Googling, I stumbled upon this, it advocates most of the guidelines we apply at my office.
    With kind regards . . . . . SQL Server 2000/2005/2012
    Wim

    Grabel's Law: 2 is not equal to 3 -- not even for very large values of 2.
    Pat Phelan's Law: 2 very definitely CAN equal 3 -- in at least two programming languages

  8. #8
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    The short one looks pretty good.

    The NATO document is useless because it is more than two pages long.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  9. #9
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Teddy View Post
    The short one looks pretty good.
    i note that he no longer (as of 2003) believes in embedding the table name at the front of all columns names

    now, if only we could find the idiot(s) who continue to teach newbies to name all their tables with "tbl" at the front of the name
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  10. #10
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    I only recently broke myself of that habit. I was using Hungarian notation in my client code too.

    It was a dark time.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  11. #11
    Join Date
    Jun 2005
    Posts
    319
    Quote Originally Posted by Teddy View Post
    The short one looks pretty good.

    The NATO document is useless because it is more than two pages long.
    +1

    When I first started programming SQL, the company I worked for used '_' to separate words which I still prefer today, but many companies have their standards so you need to adapt to whatever they want. They also capitalized all of the words, also known as SCREAMING_CAPS.

    I am still on the fence of using [id] as the name for all auto-increment PK column names, I do like PK column names to match FK column names so I can intuitively find all references.
    Last edited by Gagnon; 02-28-11 at 16:21.

  12. #12
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    I used to use SCREAMING_CAPS for DATABASE_NAMES, PascalCase for TableNames and lower_case_underscore for field_names.

    Lately I've been at clients who use pascal case for everything and it irks me. Obviously the name of the game for hired guns is flexibility. That said, I don't like not knowing what general type of entity I'm working with without a reference.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  13. #13
    Join Date
    Aug 2004
    Location
    Dallas, Texas
    Posts
    831
    We had punch cards documentation when I began programming. Try and blow a hole in that logic.

  14. #14
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    No problem.

    Now where did I put that hole punch...
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  15. #15
    Join Date
    Aug 2004
    Location
    Dallas, Texas
    Posts
    831
    yuk yuk yuk

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •