Re: Tables in a database

Mark Fisher <fisherm@britannic.co.uk> wrote: :Thanks for replying. Unfortunately the tables are being forced upon us by :the application: Business Objects. B.O. creates a repository that handles :the users security etc. and we cannot control the structure, but each :universe repository needs to have its own set of tables. I may have to :rethink whether we will allow 2 repositories which would remove the need :for multiples on the same d.b. : :The contractors who are in helping us set up the repository just keep :saying *really* useful things like "You wouldn't have this problem with :Oracle" or "You can do that on Oracle". I bite my tongue. If this is a database for reporting only (OLAP, DSS or whatever) it *may* work to set it up in mode ansi. That would make it possible to have the same table for different owners in the same database. It does however also require that the owner is allways spesified when you want to read from any table that is not owned by the current user. That alone may be too much to demand. Otherwise I will also stress that the *may* above is important. There are many strange things happening when you go to mode ansi. To your Oracle frendly consultants I would say "See, you get it with Informix as well. With Informix you do however have the added benefit of not having to use mode ansi." I have no clue wheter Oracle can do that as well, but who cares with such an attitude. The real problem is of course with Bussiness Object whose designers obviously don't know how to design a proper database. I do however appreciate the difficulty of getting them to understand that, and the even larger difficulties in making them do anything about it. Hope your solution with only one repository works out to your satisfaction. It would be interesting to here again from you about your experiences with Bussiness Objects and the general quality of the product when you have been able to use it for some time. :Mark Fisher :Britannic Assurance : :-- : :Nils Myklebust wrote: :> :> Most of the time when you have a problem like this you should either :> be able to solve it via temporary tables (where each session can have :> one of the same name) or some other simple construct. Sometimes an :> extra column with the username in a common table may be appropriate. :> :> If you post something about what you intend to achieve someone might :> give you more ideas. Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org