Code and core tables in different schemas

Question

Hi,
My db version : Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
I would like to understand, the pros and cons of the following situation:
We have a single application.
The db design for this application has 44 tables out of which 28 are core tables related by PK and FK relationships. The remaining 16 are look up and reference tables which are not related to any.
The team decided to place the 28 core tables in one schema A and the remaining 16 in another schema B within same database. (The reason for this is..since it is done in other projects lets do it here too).
Now comming to the code (stored procs, functions, packages etc). The teams wants to place most of the code in the schema B that has the 16 ref tables. (the reason again being the same).
What are the pros and cons doing this???
Please advice.
PS:
I have googled and found sth on these lines:
cons: 
o harder to manage
o harder to upgrade
o harder to patch
o harder to maintain
o causes your shared pool size to increase 1,000 times (shared sql goes down the tubes)
o takes more space
o queries against the dictionary will be impacted
o latching on the shared pool goes WAY up (latching = locks = serialization device =
slows you down)
pros:
o none that I can think of.

Answer 1

>
I would like to understand, the pros and cons of the following situation:
Yes I am straining to find more points (was not good at it though).
>
You just want to understand? Are you sure? Your thread reads more like you just want to do things your way and are looking for support.
>
The team decided to place the 28 core tables in one schema A and the remaining 16 in another schema B within same database. (The reason for this is..since it is done in other projects lets do it here too).
Now comming to the code (stored procs, functions, packages etc). The teams wants to place most of the code in the schema B that has the 16 ref tables. (the reason again being the same).
>
My question to you is: what PROBLEM are you trying to solve? If the 'team' already uses this approach and there haven't been any substantive problems then why try to change things now? Why have you chosen to fight this battle?
Your 'team' has already decided and now, after that decision, you want to argue about it with them? The time to present arguments for/against a given plan is BEFORE the decisions are made, not after. Once a decision is made you need to be a team player and implement that decision to the best of your ability.
One thing I'm certain of. If you try to support your argument using things like that 'AskTom' link you posted any credibility you had will go out the window. That link, as you already hinted yourself, is not your use case at all. All it takes is for one of your 'team' members to point that out and everyone will pretty much stop listening to any other arguments you make.
People are generally not going to 'change their ways' unless you can show them:
a) there is something seriously wrong with the way they are now doing things or
b) a new way of doing things provides some substantial benefits
Choice 'a' above is where you need to start but you haven't provided ANY information in this post that you have identified any serious issues with the status quo.
The main task for Oracle is to be able to FIND the objects being referenced. So, in my opinion, that is what you should focus on when looking for PRO/CON arguments.
That is: What issues are there if an object being referenced is in a different schema than the session that needs to use the object?
1. objects may need to be prefixed with the schema name
2. public or private synonyms may need to be created/maintained to avoid having to deal with item #1 above
3. new grants may be needed to implement/maintain the proper security
4. new roles may need to be created to maintain proper security (see item #3 above)
5. additional work will be needed to maintain the new roles in item #4 above
6. PL/SQL code may not be able to reference the object or may reference the wrong object
7. Roles are disabled in PL/SQL (see item #6 above) - this means that the new grants (see item #3) may need to be granted directly to the schema users that need access instead of to roles. That can make it harder to create and maintain a role-base security schema.
If I were you I would spend my time on other more important thingsd. But if I chose to fight this particular battle then I would make a list of problems that occured in the past with the current method of doing things and also problems related to the above list of items and then show how many of those problems will 'disappear' if the new method is used.