Schema Design.
Date: Thu, 9 Dec 2010 10:28:01 +0000 (UTC)
Message-ID: <idqavh$v3t$1_at_news.eternal-september.org>
We've got a few applications that currently all use the same schema (let's call it "FRED"). There's a main application that all our clients have, & a few add-on optional apps. We're about to start building a couple of new apps (both in APEX), which again will only be available to clients with the main app, but which will have some new tables (& plenty of procedures) that are only used by them.
Some of the new objects will be used by both the new apps, & some by just one of them. Additionally we're also planning to re-write the existing main app (again in APEX), at which point it too will use some of the new tables/procedures, but mainly it will stick with what's in the current "FRED" schema. With me so far..?
So what I'm trying to figure out is the best way to map applications to schemas, bearing in mind this is a database & applications that we install & maintain at various client sites. I don't want to stick with using a single schema for various reasons.
A separate schema for each app is one option, but who gets the tables/procs used by multiple apps? We could use a "SHARED" schema for those, but I suspect that would get messy as people develop app-specific objects in the future then realise they could be used by other apps too & move them to "SHARED". Either option could be a nightmare when it comes to remembering to put schema. in front of the object names, not to mention the potential re-work needed if objects are moved to different schemas.
Thoughts anyone?
-- Preston.Received on Thu Dec 09 2010 - 04:28:01 CST