Cleaning Bad Database Design

  • When is it absolutely necessary to take the time to go back and redesign poorly planned out tables?

    When our intranet was first designed, noone had a clue about page sizes, table sizes, ect. Even now, knowledge is slim.

    There are a number of tables that have multiple 8000 character varchar fields. SQL 7.0 used to give warning messages when fields were being truncated but it would go ahead and perform the operation anyways. But now, with SQL 2000, fatal errors pop up.

    Is this a moment in time that we will be forced to deal with our sins? Or is there a work around that will allow us to keep collecting data and periodically truncate it when the row size exceeds the maximum allowable size?

    All input is welcome. I have to decide wether it is worth the week or so that it will take to go through all sp inserts, sp selects, ASP pages, client side scripting, table designs, ect. to alter them to use a different and better technique to store long fields.

    Thanks in advance,

    -J

  • I tend to do this on an ongoing basis. To revisit an entire design is not usually practical or possible given uptime needs.

    In my last job, we would contstantly identidy those areas where we wanted to redesign and tackle them one by one to implement the changes.

    A pretty good reference:

    http://www.joelonsoftware.com

    Steve Jones

    sjones@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/sjones

  • Or just the economics of it. I try to fix whenever we have to do something that involves the same general area.

    Andy

    http://www.sqlservercentral.com/columnists/awarren/

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

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