Re: same application on multiple schemas
Date: Fri, 10 Apr 2009 11:54:44 -0700 (PDT)
Message-ID: <b67491c2-9c57-4dcd-a57b-145f00fcafd0_at_x1g2000prh.googlegroups.com>
On Apr 10, 10:36 am, Jeremy <jeremy0..._at_gmail.com> wrote:
> In article <ujLDl.13115$%54.9..._at_nlpi070.nbdc.sbc.com>,
> maus..._at_firstdbasource.com says...>
>
>
>
>
>
> > Jeremy wrote:
> > > In article <M7IDl.4500$im1.4..._at_nlpi061.nbdc.sbc.com>,
> > > maus..._at_firstdbasource.com says...>
> > >> Alberto wrote:
> > >>> Hello, I'm designing a new big application.
>
> > >>> The application will be instantiated for multiple users. Each
> > >>> application must have its own "database", or schema, Oracle speaking.
>
> > >> How many users per schema? This "scheme" sounds like a disaster waiting
> > >> to happen. Do they need separate schemas or do they need separate
> > >> databases instances?
>
> > > Why should it be a disaster waiting to happen? Suppose you were
> > > providing and appplication for multiple customers on a single database.
> > > And suppose one of those customers used the system far more heavily than
> > > other customers and it was decided to separate that user on its own
>
> > There are CPU/performance governors for that.
>
> > > database or server? Having a schema per customer then makes it easy to
> > > move it to another location.
>
> > or so you think. If you gauge your customers correctly, you will build
> > the infrastructure to handle any workload prior to deployment.
>
> You may the same app used by a 10 user company or 500 users. A
> customer's use may grow far more rapidly than ever anticipated.
>
>
>
> > > Another valid scenario might be that the
> > > customer starts off with the system hosted by a supplier but wishes an
> > > option to host on its own environment down the line.
>
> > given your initial post,
>
> It wasn't my post, I was just commenting that I can think of a number of
> sceanrios where it provides great flxeibility - really to counter your
> "disaster waiting to happen" which I still believe to be OTT.
>
> --
> jeremy
I'm with you, Jeremy, as I have this scenario In Real Life. A department was spun off to a separate company, the software is able to handle multiple companies within a schema, but eventually the company could possibly be moved off to its own hardware. So I chose to migrate to another schema, with the explicit expectation it could change to an instance which may be elsewhere. The political issues involved are much more difficult than the technical issues.
It helps in this case that the app is written db-blind, and could run on SS, those issues Michael, Mark and Sybrand refer to are real, but already dealt with. Even with that, it still scales better in Oracle. And I would still recommend using Oracle features and design-think (Alberto, see Oracle By Design and other books by Tom Kyte), and not making a new big app db-blind, unless there are specific business reasons to do so.
jg
-- _at_home.com is bogus. http://www.indeed.com/salary?q1=Oracle+DBA&l1=Irvine%2C+CAReceived on Fri Apr 10 2009 - 13:54:44 CDT