VPD vs Multi Schema vs Partitioning

Question

Hi Oracle Gurus,
We will develope a web based ERP application for a company with multi branch (about 20), with the following requirement :
- a normal user can only see and update data for his branch
- some users from head quarters can see ALL data from ALL branch
- reporting will be per branch, but there should be Consolidation reports
Total user will be 200, but maximum concurrent is 60 users.
We will use JSF(ADF Faces) + BC4J, one database server and one apps server.
The question is :
To meet the requirement above about which user can see which data, what Oracle feature should I use :
is it VPD ?
or should I just use different schema for each branch ?
or use Partitioning ?
Thank you for your recommendation,
xtanto

Answer 1

Xtanto
1) Using partitioning won't in itself help with the security question.
- It may help with performance (or it may well not).
2) A different schema for each branch
- is simple and scalable for branch applications,
- but is a total pain in the neck for consolidation (you will create lots of reporting UNION ALL views)
- and it makes it harder to deal with session pooling in the Java application tier if that ever becomes necessary (because you need a separate session pool for each branch, and one for the head office).
- and it works the database harder (every distinct SQL statement in the SGA is multiplied by the number of branches
- and it makes datamodel maintenance 20 times more tedious
- and you have to decide which data is 'shared' (eg employees? cost codes? customers?) and which are owned by the branch. Some data may be visible to everyone, but 'owned' by a particular branch (or equally likely, by a particular function like HR, Buying, whatever)
3) I have no personal experience of VPD itself. But I'd go for VPD or failing that for old-fashioned 'roll your own' application security (which is often implemented more or less the same as VPD, but at a higher cost to the developer). This gives you the most flexibility; it makes it possible for different users to have overlapping views of the data (eg if you add a regional structure between branches and head office, they may need to see several but not all branches).
Because you have a small app (only 60 users, only 20 branches) some of the downsides of using separate schemas are not such a big thing - but even at 20 branches, the union views will get very unwieldy... And for sure, all organisations change shape over time - don't assume that today's structure will still be in place in 12 months time!
My 2d, HTH
Regards Nigel