I started thinking about what you said. One alternative is to have a schema
per client with a shared schema for reference data. You could then use alter
session set current schema when operators swtich to a different client. That
requires almost no additional coding, but it does depend on how often
operators switch clients. There are possible issues with parsing and the
shared pool, but I don't suppose they would be a problem.
Bricklen <bricklenREMOVETHIS_at_shaw.ca> wrote in message
news:3C75C20C.819735F3_at_shaw.ca...
> We'll see I suppose how things turn out, if I can squeeze some cash out
> of the boss. We're in a small shop here -- I'm in charge of the
> dba/developer duties. Keeps things interesting, to say the least.
>
> The option I mentioned, about manually creating my own tables etc. to
> mimic partitioning (which I'd rather avoid having to do if possible!),
> is something that I will experiment with to see how it goes.
>
> We don't do a lot of cross-client querying anyways, so the effect of
> specific tables per client may not be that bad of an idea.
>
> Thanks for taking the time to reply to my earlier posts.
>
> Cheers,
>
> Bricklen
>
> Keith Boulton wrote:
> >
> > Sounds viable to me, because it is essentially the same thing as
> > partitioning does anyway.
> >
> > Bricklen Anderson <bricklen13_at_hotmail.com> wrote in message
> > news:b416ca2d.0202210805.4e91ca71_at_posting.google.com...
> > > I should probably clarify why I asked the question...
> > > My employer is, shall I say... cheap, and the chances of getting EE as
> > > well as the partitioning option are prettttty slim. I have used the
> > > EE + P.O. in my test database (as a trial), and the benefits were
> > > numerous. Most of the uses of PO are not necessarily crucial to our
> > > environment however, so I'm always looking for ways to improve
> > > performance. A thought of mine was to create tables based on the id
> > > of each client (about a 100 clients), for quicker response time when
> > > generating reports etc. We currently have about 60 million rows in
> > > our main table, which isn't huge, but within the next few months that
> > > is expected to increase to about 500M rows.
> > >
> > > just wonderin' if any of this sounds viable.
> > >
> > > Cheers,
> > >
> > > Brick
Received on Fri Feb 22 2002 - 02:24:39 CST
