SQL Server 2005 Best Practices

  • They have actually done a really good job with Books Online from my experience, and there are certainly a bunch of specific recommendations there, but it's not in an easily readable "white paper" format.


    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek


  • Is it OK to install SQl Server 2005 final on my laptop?

    Our current production environment is VS.NET 2003 and SQL Server 2000. I would like to install SS2005 to play around. Would that impact previous dev tools?

    Thanks in advance.

  • I agree with others that this is a nice list of the new features but not Best Practices.

    I would not advise to reset Compatibility Level because your current version of your application may use features that are not supported on 2005. The exaple is an industry leader CRM application ( I don't want to name names) where I ran an Upgrade Advisor.

    For the Best Practices I would start with ones for developers and ones for sysadmins. Updrades are fine, but what about the new installations? I am still waiting for the best practices for placing features on the drives for 2005. In 2000 I would put Program Files on the OS /Program Files RAID 1 and Data Files on RAID 5. In 2005 when you install, the Data Files feature is a subfeature of Database Engine feature. And I would not put feature and its subfeature on separate drives. This is just an example of what could be a best practice advice.

    Regards,Yelena Varsha

  • I'd like to hear a response from the author of this article on the DBCC statement.

  • I cant believe I went through the registration process to read this article. Please rename it from 'best practices' to 'upgrade options and new features'.

  • Yes, I was looking for a best practices document outlining such as in this doc for sql 2000:


  • What does this mean:

    "If you are using any object type code as ā€œSā€ this will not work. System tables (S) are not exposed"

    Does it mean you can not use S as a table name for instance?

  • Think you are referring to the 'type' column in sys.objects

    From BOL, values for this are

    type char(2) Object type:

    AF = Aggregate function (CLR)

    C = CHECK constraint

    D = DEFAULT (constraint or stand-alone)

    F = FOREIGN KEY constraint

    PK = PRIMARY KEY constraint

    P = SQL stored procedure

    PC = Assembly (CLR) stored procedure

    FN = SQL scalar function

    FS = Assembly (CLR) scalar function

    FT = Assembly (CLR) table-valued function

    R = Rule (old-style, stand-alone)

    RF = Replication-filter-procedure

    S = System base table

    SN = Synonym

    SQ = Service queue

    TA = Assembly (CLR) DML trigger

    TR = SQL DML trigger

    IF = SQL inline table-valued function

    TF = SQL table-valued-function

    U = Table (user-defined)

    UQ = UNIQUE constraint

    V = View

    X = Extended stored procedure

    IT = Internal table

  • Agreed, not a best practice list. Some good information. You should have a 'tips' section - or simply a 'best practice' that others can add to and maintain.

    Jim Teaks



  • The article seems incomplete and it is not a 'Best Practice' ariticle also. There are lot of gaps in the informations.


Viewing 10 posts - 16 through 24 (of 24 total)

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