June 11, 2012 at 8:54 am
MysteryJimbo (6/1/2012)
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.
MysteryJimbo (6/1/2012)
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.
Hi MysteryJimbo,
Thanks, noted both. Also, would you please help me with some questions to ask customer to know about the current status of the existing database. We are not yet started the development.
_____________________________________________
One ounce of practice is more important than tonnes of dreams
June 11, 2012 at 9:04 am
Jeff Moden (6/1/2012)
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?
Hi Jeff, Thanks.
They have already cleared this in their initial requirement doc. They are finding difficulties to manage more than one server in different locations and issues with redundant data from different vendors. If it is in a single place they can avoid bot.
_____________________________________________
One ounce of practice is more important than tonnes of dreams
June 11, 2012 at 9:05 am
manus4u (6/3/2012)
Hope u know me ;-)!!Port no (incase if they aint using the default one).
&
Service Accounts
Yes Manu,
I know :). Noted both points.
_____________________________________________
One ounce of practice is more important than tonnes of dreams
June 11, 2012 at 9:08 am
Eric M Russell (6/4/2012)
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?
Hi Eric,
Both !!! They want to consolidate both databases and servers to a single place. They are having difficulties to maintain and manage more databases and servers.
_____________________________________________
One ounce of practice is more important than tonnes of dreams
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply