| Multiple databases [message #90423] |
Thu, 31 July 2003 04:19  |
Subrahmanyam R V
Messages: 1
Registered: July 2003
|
Junior Member |
|
|
Hai friends !
Iam from Hyderabad,India having the following issue.
I may kindly be given a solution to this(cost effective as well as user friendly)
Issue :
-------
I have an application running on 9i,8i and some sites 7.3. Now our admin wanted to combine some of the sites into a single host and put 3 tier architecture. And this kind of single hosts will be placed region-wise.
Now, as far as the db design is concerned, we were asked to submit various options.
We thought of the options as follows.:
( each site data size is between 3-5 Gb. Users between 150-400 ..depends on the size of the site )
1. Single database --- catering service to all sites
2. Multiple dbs --- in the same host.
3. Multiple schemas in the same db
We thought, the third option will have a synonym problem as the same object is availabe in multi-schemas.The users having previleges on a schema will have a problem in this case.
** You may kindly give me the pros and cons w.r.t. these options.
With regards
Subrahmanyam , Hyderabad,India
|
|
|
|
| Re: Multiple databases [message #90424 is a reply to message #90423] |
Fri, 01 August 2003 10:17  |
Mark
Messages: 284
Registered: July 1998
|
Senior Member |
|
|
Wow. That sounds like a great project. I was involved in something similar at a previous job.
The dba/developer shop I worked in supported manufacturing lines and shipping points in three different locations (two in US, one in Mexico). Each had their own local databases. There were many factors involved in making our decisions and many lessons learned when we executed our plan. Here are some of the things that were weighed.
1. What were the most critical components of our business? We had to quantify the potential impact of poor network connectivity. In our case, one of the manufacturing lines could not be stopped (24x7 operation) and the shipping could not be interrupted. We designed our architecture with this in mind.
2. Ambiguous naming convention between databases. You have to quantify this. We determined that it was better to correct our ambiguous naming conventions before we started reorganizing our database architecture. It set us back weeks, but in the long run we were better off.
3. Ambiguous codes/processes were also a problem. Since our lookup tables were all maintained locally, we had to identify every code that was used differently at each site. For example, the number of test result codes used in one plant was far greater than in another plant. This was the result of one plant having better, more mature business processes. We claimed we could not support two different business processes with the new architecture, and thus forced the other plants to adopt the better business processes.
4. Inconsistent use of forms and obsolete applications. In an effort to not waste time recompiling or recoding applications that were not used, we gathered usage statistics. These statistics also proved invaluable when evaluating business processes. It also enabled us to compare our maintenance costs to value to our users.
5. Detailed, step by step implementation plans were absolutely necessary. These plans must include steps to back out of the implementation and recover the legacy system in case something catastropic occurs. We did not have to back out, but we understood all of the risks before we started the implementation.
6. This will happen. Pad your estimate of how long the implementation will take so you can take credit for finishing early, or at worst on time.
Hope this helps,
Mark
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
