oracle的三种用户,Oracle用户是应该设计为这三种角色，还是将所有的application用户都建为Oracle用户？...

本帖最后由 liklstar 于 2014-7-16 13:15 编辑

不，他说得似乎有一定道理！

Tom

I agree with your suggestion if

1)You have handfull of users to manage or

2)You really dont care about the number of concurent connections and resource reusability and

connection effieciency.

If you have a 3/N-tier architecture, using single oracle account and managing access/roles in

application layer is more effeicient and scalable. Also most of the comercial class applications

use LDAP kind of service for autentication and user account management.

So the decision would be based on the requirement. Long term, Short Term, Scalable or Quick and

Dirty and ...

Here are my questions

1)Please do let me know if you you how your 1 account per user would work in a N tier env, other

then making a dedicated connection for each user.

2)Is there a way to make the db connection independent of the user autentication. Something where

the application layer can attach/pass the user credentials with every call it makes to the database

thr a common connection?? Am I making any sense??

Thanks

Followup   October 19, 2002 - 10am UTC:

Well, I run a system with 40k users.

It is n-tier.

I *do care* somewhat about those things (trust me, i do).

I argue it is NEITHER more efficient NOR more scalable.

I argue that what it does it lock the data into your application, limiting its reused.  N-tier is

just "todays" architecture.  Just like host based was last centuries and client server was after

that.  There will be some other architecture.

By doing these crucial things in the APPLICATION ITSELF, you are locking yourself into an

architecture for ever (many of the client server and host based systems are out there not cause

people want them -- but because they cannot move OFF of them -- the logic is all wrapped around

itself in the application -- you cannot access the data safely/securely WITHOUT the app).

See

http://otn.oracle.com/docs/produ ... fundamen.htm#100639

2

for a description of proxy authentication.

It lets you setup a PHYSICAL connection to the database and then "set user" within that connection.

The physical connection -- slow.  The "set user" is just setting up a session state (something YOU

MUST do anyway with a connection pool -- you cannot let bits of a previous state hang out across

connections)

#2 not only makes sense -- we do it.

Tom认为：用app管理用户“即不高效，也缺乏可扩展性”。如果不将apps用户建立为Oracle accounts，那么对于“集中式”应用和“client/server”应用就无法使用。不仅如此，如果使用apps用户和验证方式，那么在没有此app的情况下访问数据库就是不安全的！

诸位的意见呢？