Re: Schema Design.
Date: Thu, 9 Dec 2010 10:38:02 +0000 (UTC)
Message-ID: <idqbia$r5i$1_at_news.eternal-september.org>
On Thu, 09 Dec 2010 10:28:01 +0000, Preston wrote:
> 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?
Don't hard code schema names in application code; use synonyms. Received on Thu Dec 09 2010 - 04:38:02 CST