3 varbinary(max) columns in one table

  • I am creating a vendor table for internal use.  The table has three varbinary(max) fields along with a few other columns.  I am concerned about performance issues with the three varbinary(max) fields in one table.  I know there is an 8,000 byte limit per page and if our varbinary(max) fields exceed this limit there will be pointers to other pages where the remaining data is stored.

    I researched a design pattern that seems to alleviate some of the pressure on the database by taking the three varbinary(max) fields and creating a new related table.  The table would have a primary key, foreign key to the parent, a document type column (possible values: XML, originaldocument, draft), and one varbinary(max) column.  The benefit of this design is that there is only one varbinary(max) column per row instead of three.

    This design, however, is from 2000.  There is another school of thought that SQL Server has come a long way since 2000 and that with appropriate memory and RAM one table with three varbinary(max) columns might be fine.  In addition, the one table version is only going to store 30 days’ worth of data.

    I am curious as to what the group thinks about having three varbinary(max) fields in one table and if SQL Server can handle it without significant performance degradation?  Any thoughts would be greatly appreciated.

  • Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • Because of a rather insidious change that MS made for the new LOB datatypes compared to the old ones in 2005, most people's usage of LOBs causes huge problems and tons of wasted memory due to "short row entrapment" and totally unnecessary "ExpAnsive Updates".

    Please post the CREATE TABLE statement along with all indexes, constraints, and defaults that are used on the table.

    --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)

Viewing 3 posts - 1 through 2 (of 2 total)

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