Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Best way to handle data of different setups in same applicati

RE: Best way to handle data of different setups in same applicati

From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
Date: Tue, 04 Mar 2003 07:35:02 -0800
Message-ID: <F001.0055F92C.20030304073502@fatcity.com>


Aleem

   There are two considerations for placing tables into tablespaces. Size and application. Size makes sense so you can put similar sized tables together. Study LMTs and Uniform extents. Oracle recommends you put all your small tables in a tablespace with 128k extents, medium with 4meg extents, and large tables with 128meg extents. Read the white paper.

   If you think you may need to independently upgrade the applications or may need to relocate them to other systems, then keep them separate. Otherwise there is no problem mingling the tables in the same tablespaces.

Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Tuesday, March 04, 2003 7:19 AM
To: Multiple recipients of list ORACLE-L

Hi,

Now that URGENT! applications are in place, we do not have much pressure from our management so we can do some real planning of our database.

I would much appreciate if you could give your expert opinion.

TIA! Aleem

We are going to start with General Ledger as our first (hoped to be) planned application. The GL will handle 4-5 different setups (sort of sister concerns), different setup means different chart of account. I am sure that you understand that the application otherwise is exactly the same. The average size of a years data of each setup is around 150MB.

Next we would have other similar applications for example payroll and HR. All these application will have some tables sharing data with each other. Like for example the financial year table, the table holding company's and sister concerns' information etc. Eventually there would be 10-15 such applications. Number of users of each application would be 2 to 10. There is a possibility of web deployment of these applications, in case one of the setups needs to operate from a different location thus changes its office.

The broad picture that I have in mind is: Use different table space and data files for each application (feel that if one gives problem will not affect other applications) Create a user for common tables (shared amongst multiple applications) and use public synonyms for these tables with appropriate rights. Create a user for each of the application to host data of all setups. The application will use the same username/password to connect to the database ON_LOGON Trigger. The user privileges will be maintained by the application.

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Abdul Aleem
  INET: dmit_at_beaconhouse.edu.pk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM
Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Tue Mar 04 2003 - 09:35:02 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US