Re: Only one Account for all users - How bad it is ?
Date: 1996/02/29
Message-ID: <Pine.SUN.3.91.960229160950.19979A-100000_at_seatimes>#1/1
On Tue, 27 Feb 1996, Brad Bruce wrote:
> milapier_at_ge.hydro.qc.ca (Michel Lapierre) wrote:
>
> >We are developping an application and we are forced to use only one
> >account for all the users. We could have more than 100+ users.
>
> The problem you will run into is that you could run out of processes.
> The number of processes performed by Oracle is limited for each user.
The biggest problem I see is an administrative one. How will you determine which user is which? Especially when operations wants to shut down and there is one lone user still active.
From the applications perspective, they shouldn't care what the user name is as long as they have the proper access to the files. That can be done with roles.
The approach we are using involves a default role that gives limited access (mainly for reporting). Another role is granted but requires a password for the user to enable. The application program knows that password and will enable that role when the user connects via the application. Otherwise, the user is unable to damage the data.
In this manner, the DBA can keep track of who is attached to the database. It also makes it easy to remove privileges from an individual rather than forcing everybody to learn a new common password (which becomes widely known soon thereafter).
--Steve
PS Every table I build as the following columns:
UPDATED_ID VARCHAR2(30) * Oracle user ID who inserted/updated
UPDATED_DT DATE * System date/time when inserted/updated
UPDATED_SEQ NUMBER * Starts at zero and is incremented
for each update against the row.
These three are maintained by triggers and ignore whatever the application may attempt to put into the columns.
+----------------------------------------------------+ | Steve Butler Voice: 206-464-2998 | | The Seattle Times Fax: 206-382-8898 | | PO Box 70 Internet: sbut-is_at_seatimes.com | | Seattle, WA 98111 Packet: KG7JE_at_N6EQZ.WA | +----------------------------------------------------+All standard and non-standard disclaimers apply. All other sources are annonymous. Received on Thu Feb 29 1996 - 00:00:00 CET