Re: Multi-database table references

On Sep 25, 6:02 pm, Karl & Betty Schendel <schen...@xxxxxxxxxxxxxx>
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

.

Relevant Pages

  • Re: polymorphism (was: Poly Couples)
    ... but this is not really "business software"... ... Most of such applications are built as a combination of ... database with flat files or a different RDBMS vendor?" ... couldn't care less if I do it in using structured programming or OOP ...
    (comp.object)
  • Re: Unisys OS/2200 DMS / TIP / COBOL Migration
    ... support the legacy system api's that the application is using. ... differences in COBOL compiler dialects. ... What DBI does is to provide legacy database (DMS) ... the legacy database to the COBOL applications. ...
    (comp.sys.unisys)
  • Re: Database set up help
    ... let's see...I choose the y/n data type because I am using ... User opens up form and enters Employee Information in the fields ... 2 of the 38 options in my main menu are BPCS Applications ... I set up a database with this so far: ...
    (microsoft.public.access.gettingstarted)
  • Re: Advice needed for a growing Access 2000 project
    ... However, it turned out that quite a few of those were "leftovers" from previous releases, no longer accessible from anywhere but the database window, and, thus, no longer used. ... But that certainly isn't the _norm_ -- without any 'heroic' measures, there are routine reports of split Access DBs ... Finally, in my opinion, for "Windows apps", that is, individual-user applications, modest-sized multiuser applications, and client-server applications of any size, Dot Net does NOT "help along" any of these issues. ... The post I reference was in reference its self to the MS Access Help file under "Microsoft Access database general specifications" ...
    (comp.databases.ms-access)
  • Re: POD speed
    ... But I do think that there are costs to making a design decision ... > an OO data persistence layer that happens to use a relational database ... Would you see it as reasonable that two applications accessing the same database tables ... > what a business software system will be like years from now. ...
    (comp.lang.java.databases)