[Info-Ingres] Multi-database table references

[Raghavan]

On Sep 25, 6:02 pm, Karl & Betty Schendel <schen... at kbcomputer.com>
wrote:
> At 12:10 PM +0000 9/25/07, Raghavan wrote:
>
> >I think we are narrowing down to the problem/solution.
> >S, We have One huge database with multiple applications (80 odd
> >applications). I need to club 4-6 related applications to one
> >database. However, each database will access the tables from some
> >other database(s) . Scenario will be for select or for insert or for
> >update.
>
> >what I understand is Ingres STAR should suffice to my conditions.  I
> >hope I am correct.
>
> I think you are making a mistake, and should simply leave things
> alone.  The whole idea of a "database" is that you store things
> in it that applications need.  If you can't slice the database
> into independent pieces, you should leave it as one database.
>
> There is nothing wrong with having a "huge" database.  Chopping
> it into pieces is not going to make it any smaller;  and if
> there is no logical partitioning, chopping it up is not going
> to make it any more maintainable or understandable either.
> (I will admit that more, smaller databases might be easier
> to checkpoint and maintain, but again, not if multiple db's
> are in use simultaneously.)
>
> Yes, Ingres/Star can allow you to chop up the database into
> a number of subsidiary databases, and it will allow you to
> present a view of the subsidiaries (Star calls them local databases,
> or LDB's) as one combined database.  But why?  Why take
> things apart only to put them back together?
>
> Star will restrict you in various ways as to the SQL you
> are allowed to use.  (For example, Star doesn't support
> outer join, nor does it support session temporary tables.)
>
> Maybe if I knew the whole situation I would feel differently,
> but I doubt it.  I think you are going to expend a lot of
> work and end up with something that is slower, harder to
> understand, and harder to maintain than what you have now.
>
> Karl

Hi Karl,

I understand your view point. This is the reason, when we started in
1990, we started with SINGLE database. however, after having worked
and inducting more and more functions in the last 15+ years. The
situation has come now, wherein
1. we need to include lot of GUI based applications and introduce work
flow and also increase our number of users from 600 to may be 4000.
2. this is definitely a re-engineering, but we would like to estimate
on amount of saving that we can on the character based system which is
already in place and which will remain in place.
3. it is also a question of security that different function/area
(like Personnel, Accounts, Inventory, Academic, etc) will have
different DBA's. we are only 4 members as of now. We need and are
planning to expand our team as well. The applications are 24x7x365.
I hope I have expressed a lot of my thoughts.
Thanks
Mrs Raghavan