Single schema or multiple schemas

Question

Hello
A few years ago I worked on a greenfield project where we were building a system to serve 20 or so different departments with 1200+ users. The approach the existing DBA had taken was to use a single schema for all objects and for all apps. The big advantage I found with this approach was for development, we could have one database and each developer could develop whatever they wanted in their own schema. Name resolution meant that they could override the main copy of whichever object they were working on just by having it in their schema. Unfortunately the project went nowhere and I left after 3 months so I never got to see what issues were raised with the system in production. So I'm wondering, has anyone else taken this approach and if so what would you say are the main things to be wary of? Especially things that aren't a problem when the objects are distributed between multiple schemas.
Thank you in advance
David

Answer 1

user12065404 wrote:
Hi Ed
Thank you for your reply. I think I need to clarify what I meant a little.
On a number of sites I've been to there have been multiple applications spread out over multiple schemas for the same business unit. To draw on the emp example it would be like having the EMP schema containing the emp table and the DEPT schema containing the dept table, with a single HR application (for a single buisness unit/department) selecting from both. If you scale this up to 000s of tables and 30 odd schemas, it's a bit of a nightmare from the perspective of code location and permissions because each department needs to look across schemas to get all of the data to do their job. Effectively tables and code had become segregated into separate schemas by business "function" and it means that the applicaitons are so intertwined with the different schemas that to have more than one business unit means you either need a completely separate database or you have to look at VPD.
App         SCHEMA      Table
HR          emp         emp
dept        dept
Invoicing   emp         emp
invoicing   inv
contracts   contract
orders      ORDER
Ordering    emp         emp
contracts   contract
orders      ORDER
orders     orderitem
...The advantage I saw with a single schema for all the data for a single business unit is the one you have mentioned - i.e. you can very easily set up a new business unit that is totally separate from the other by having a new schema and point the same version of the same application at it. Or failing that, using VPD. And on top of that, security is simplified - no needing direct grants from one schema to the other and especially not requiring WITH GRANT OPTION in the case of a view that pulls data from various schemas and rights to select from the view have to be grated to a role.
App         SCHEMA      Table
HR          abc_ltd     emp
abc_ltd     dept
Invoicing   abc_ltd     emp
abc_ltd     inv
abc_ltd     contract
abc_ltd     ORDER
Ordering    abc_ltd     emp
abc_ltd     contract
abc_ltd     ORDER
abc_ltd     orderitem
...The other big advantage I saw was from a development and testing perspective. You can have one testing database supporting lots of developers working on lots of different projects against the same core data set and code. The multiple schema setup I described above means that effectively you need to have one testing database per project - which becomes unmanageable when databases start growing to the TB range.
David
Edited by: user12065404 on 26-Mar-2010 08:30
Saw a typo in my first exampleOK, now it is a lot more clear.
What you have here is a problem of some data (employee) being enterprise data, and other data being application data.
I take it your "invoiceing" app is used by the sales side of the business, and "ordering" is used by the purchasing side (my last assignment when I was an apps analyst was the purchasing/inventory control for an auto manufacturer).
With what I know at this point, I'd have an HR schema, an INVOICING schema, and an ORDERING schema. (Well actually, I'd have SALES and PURCHASING, because INVOICEING and ORDERING are going to have to integrate with other stuff in those areas). Even though invoicing and ordering both have a CONTRACT table, I'd think the properties of a contract for one would be different than the other, so the table design itself would be different. How about tables SALES_CONTRACT and PURCHASING_CONTRACT. Same concept for ORDERS, and both sales and purchasing would need header and details .... SALES_ORDER_HEADER, SALES_ORDER_DETAIL, PURCH_ORDER_HEADER, PURCH_ORDER_DETAIL.
These two apps need for employee data should be pulled directly from the HR emp table, with access limited to stored procedures that control what data is exposed. Or from materialized views. Never try to maintain the same data in two places at once. It will never maintain consistency.