Much of it also depends on how your SQL Server apps were designed. If
your apps require the users to be defaulted to certain databases, it's
going to be tough. Some people use public synonyms, but this approach
doesn't work well if you have two objects with the same name. The best
thing is of course predicate your objects with schema owner name, but
this could be a double-edged sword, too: a) often 3rd party
applications simply don't do that and b) if you have home-grown
applications, migrating your code from development to test and finally
to production is simply a pain.
--
Jining Han
Sallie Mae
In article <Xns902DA022CCF33audun.jyahoo.no_at_130.133.1.4>,
audun_j_at_yahoo.no (Audun Jensen) wrote:
> Hi,
> I'm starting to migrate a MS SQL Server db to Oracle and have some
> questions I would like to have comments on.
> Today our SQL Server database consists of more than 3500 user
databases and
> the number is increasing. Each database corresponds to a
user "project". As
> some of you probably are aware of, SQL Server have a "database"-
concept
> that differs from Oracle's, in the way that one SQL Server instance
can
> consist of many databases, each database consisting of users, tables,
> views, procs, triggers etc.. I believe the way to do this using
Oracle will
> be to create and implement a schema for each database, containing the
> necessary objects and constraints.
>
> This leads to an instance containing thousands of schemas, each
containing
> 50-100 tables. In addition I will have to create users who can access
one
> or more of these "databases" depending on how many "projects" the
customer
> creates.
>
> Is there anybody who have any experience in this number of schemas?
What
> will I have to think of in order to have an instance that is
operatable and
> running smooth?
>
> TIA
>
> AJ
>
--
Jining Han
Sallie Mae
Sent via Deja.com
http://www.deja.com/
Received on Thu Jan 18 2001 - 17:57:41 CST
