Post reply

Databases

  • December 21, 2006 at 4:06 pm

    #175303

    MSSQL2000

    My SQL Server houses data from several applications, both out of the box and home grown.  Most applications must share data with each other.  Are there any suggestions or advice of when to split tables into their own database versus using just one database?  I can see the advantages of using just one database but I can also see some potential problems with either performance and/or hurdles within development.

    Thanks!

  • December 21, 2006 at 4:44 pm

    #679614

    I've always used 2 types of criteria to decide what data goes where.

    Logical:  Is this data related to the other data by application or business function?  Is this data logically dependent on other data and therefore must be kept in synchronization? 

     

    Physical: Does this data have the same availability requirements, backup/restore/recovery requirements as the other data?

     

    I'm sure there are other criteria, but those are the first questions I ask to determine placement.

    And then again, I might be wrong ...
    David Webb

  • December 22, 2006 at 8:14 am

    #679733

    Generally duplicating data is bad news, a single source of truth is usually best.

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • December 22, 2006 at 8:18 am

    #679735

    #1 consideration. You are using home-grown and vendor created databases. The #1 consideration has to be support. Most vendors do not permit changes to their database(s). If you do change them (adding or removing schema stuff), they usually will no longer support it. This can also be true if the vendor's product creates it's own instance.

    -SQLBill

  • December 22, 2006 at 10:36 am

    #679790

    Thank you all for the posts and thoughts to consider!

Viewing 5 posts - 1 through 4 (of 4 total)

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