Post reply

What are the questions should ask to the customer about the existing database?

  • May 30, 2012 at 4:19 am

    #392380

    Hi Guys,

    I need a help.

    Customer requirement is to merge 3 to 5 databases to a single database. Before proceeding to this I required to know the current details (Configuration, Load, version, users.. etc..etc) of the existing databases. What are the questions should I ask to the customer about the databases?

    Please provide your questions or provide any good existing links.

    Regards,

    Shaiju CK

    _____________________________________________
    One ounce of practice is more important than tonnes of dreams

  • May 30, 2012 at 4:37 am

    #1494556

    C.K.Shaiju (5/30/2012)

    Hi Guys,

    I need a help.

    Customer requirement is to merge 3 to 5 databases to a single database. Before proceeding to this I required to know the current details (Configuration, Load, version, users.. etc..etc) of the existing databases. What are the questions should I ask to the customer about the databases?

    Please provide your questions or provide any good existing links.

    Regards,

    Shaiju CK

    Things I can think of

    Collation

    Growth

    Archive processes

    Related SQL jobs

    Backup schedules

    Reporting requirements (logshipping? replication?)

    High availablility

  • May 30, 2012 at 4:46 am

    #1494562

    Security - ensure the users are merged and required access is given.

    Recovery Model - do you want the recovery model to be changed?

  • May 30, 2012 at 5:11 am

    #1494570

    Maintenance jobs

    Related products using those databases, such as SSIS, SSAS and SSRS.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • May 30, 2012 at 7:20 am

    #1494650

    Thanks friends 🙂

    Any more questions?

    _____________________________________________
    One ounce of practice is more important than tonnes of dreams

  • May 30, 2012 at 7:23 am

    #1494655

    And of course what the databases are used for:

    * reporting/analytics (data warehouse)

    * OLTP support for an application

    * archiving

    * ...

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • May 30, 2012 at 7:30 am

    #1494658

    Sizes of the databases

    Are there existing external connections to the data etc.

  • May 30, 2012 at 3:04 pm

    #1494924

    I would think that object name clashes would be a potential concern. If they occurred, resolving those could theoretically involve a LOT of work.

    SQL DBA,SQL Server MVP(07, 08, 09) "Money can't buy you happiness." Maybe so, but it can make your unhappiness a LOT more comfortable!

  • May 30, 2012 at 5:35 pm

    #1494967

    Merge as in "Structures are the same and the data needs to be combined" or "structures are different and objects need to all be in a common database"?

    If the former, you'll need to know the data model and the way the related columns interact (all natural keys, generated ids, any ranges of ids that mean something, any intelligence built into generated keys, etc.). If there is a possible duplication if ids, you'll need a strategy for resolving the conflicts and still keep the related data related.

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

  • June 1, 2012 at 3:04 am

    #1495735

    Mike Menser (5/30/2012)

    Are there existing external connections to the data etc.

    Hi Mike, I dint understand this line.

    ScottPletcher (5/30/2012)

    I would think that object name clashes would be a potential concern. If they occurred, resolving those could theoretically involve a LOT of work.

    Hi ScottPletcher, Yes object name clashes are there. Agreed. it is a lot of work :(.

    David Webb-200187 (5/30/2012)

    Merge as in "Structures are the same and the data needs to be combined" or "structures are different and objects need to all be in a common database"?

    If the former, you'll need to know the data model and the way the related columns interact (all natural keys, generated ids, any ranges of ids that mean something, any intelligence built into generated keys, etc.). If there is a possible duplication if ids, you'll need a strategy for resolving the conflicts and still keep the related data related.

    Hi David, Structures are partially same and need to all be in a common database. For the existing databases, there is no pk fk relations have been created (What a joke) and struggling to find out the relations between tables. Sure, will take care of that duplication issue.

    Thanks guys 🙂

    _____________________________________________
    One ounce of practice is more important than tonnes of dreams

  • June 1, 2012 at 3:17 am

    #1495748

    C.K.Shaiju (6/1/2012)

    ScottPletcher (5/30/2012)

    I would think that object name clashes would be a potential concern. If they occurred, resolving those could theoretically involve a LOT of work.

    Hi ScottPletcher, Yes object name clashes are there. Agreed. it is a lot of work :(.

    Its possible to work around this by using schema's to separate objects. This would require fewer changes in any code. I'd probably consider different filegroups for each "database" upon merge so you could have the ability to backup individually.

    What is the justification for this business requirement as I would question it myself? If the databases are on the same server they can cross communicate without impact anyway. 5 databases seems like a minimal administrative overhead.

  • June 1, 2012 at 3:19 am

    #1495751

    Another idea I've thought of is you could use a logical database (views) merging the physical databases. This would work as a testbed as well if you pursued the idea of merging. You could stage the merges one by one.

  • June 1, 2012 at 11:39 pm

    #1496170

    C.K.Shaiju (5/30/2012)

    Thanks friends 🙂

    Any more questions?

    Yes... there are two that are very important that I've not seen, yet, that need to be asked of the customer.

    1. Why do you want to do this?

    2. What are the benefits that you think you'll get by doing this?

    --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)
    Intro to Tally Tables and Functions

  • June 3, 2012 at 4:31 pm

    #1496331

    Hope u know me ;-)!!

    Port no (incase if they aint using the default one).

    &

    Service Accounts

  • June 4, 2012 at 1:00 pm

    #1496703

    One question them or perhaps just you would be:

    Are we really talking about consolidating databases that currently exist on the same server, or are we talking about consolidating servers?

    Why are they wanting to consolidate into one database; what is the goal?

    Can you speak directly with the person who chose to make that architectural decision?

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 15 posts - 1 through 15 (of 18 total)

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