Re: DB Design Dilemma!! One DB or Many DBs??
From: Mark Townsend <markbtownsend_at_attbi.com>
Date: Thu, 14 Feb 2002 02:41:42 GMT
Message-ID: <B89063E6.12021%markbtownsend_at_attbi.com>
Date: Thu, 14 Feb 2002 02:41:42 GMT
Message-ID: <B89063E6.12021%markbtownsend_at_attbi.com>
in article d4199cf5.0202111920.5d5abec7_at_posting.google.com, Rob Hindman at robhindman_at_hotmail.com wrote on 2/11/02 7:20 PM:
> Hi I have a major DB Design Dilemma !!
>
This is a classic consolidation play. Oracle has specific capabilities to address these type of requirements
- Virtual Private Database for the automatic data seperation - i.e one set of tables containing the common data for all business entities, with any query or DML automagically rewritten by the database to limit it's effect to the corresponding business unit. You can develop the application once without the need to build in the seperation logic, and the same business rules also work for users that want to access the data via ad-hoc tools etc that bypass the application. This is especially useful when you manage your users in an LDAP directory, as the directory can provide the corresponding unit information automatically (i.e key the seperation logic in the database on the actual org definitions information in the directory definition). Also a better solution than views - views work OK with 10 business units, but with 1000 (or 10,000, or 100,000) quickly become unmanageable.
- Resource management so that you can manage one business units workload requirements against another - i.e allow one business unit to close their books (run lots of reports) without this query load unduly impacting on the other units ability to post data. (Oracle concurrency control also helps facilitate this as well). Or have the resource availability managed to 'follow the sun' if your business units are global.
- List partitioning to seperate the actual physical data-to-disk layout of each business units data - so that you can have different backup/recovery service level and timetable for each one business unit if required. Couple this with pre-populated transportable tablespaces and you can add a new business unit immediately.
A number of large ASPs use these capabilities to great effect to solve exactly these types of problems. Received on Thu Feb 14 2002 - 03:41:42 CET