Creacion de usuarios almacenandos en tabla especifica

[cadesa]

Hola a todos, yo sigo con mis dudas en oracle y las cuales no he podido entender como hacer las cosas, bueno ahora mi duda es la siguientes, yo tengo una tabla que se llama "USUARIOS_APLICACION" y es en la cual pense almacenar los datos de los usuarios, eso fue sin pensar en crear los usuarios en oracle solamente leerlos desde esta tabla pero ahora quiero que al momento de crear un usuario en oracle se grabe la información en esta tabla, y que el usuario creado este asociado al registro de esta tabla.

Gracias a todos.

[kikolice]

"al momento de crear un usuario en oracle se grabe la información en esta tabla, y que el usuario creado este asociado al registro de esta tabla"

eso no se puede, en dado caso lo puedes hacer al reves, cada que se registre/elimine un usuario en tu tabla se cree/elimine el usuario en la base de datos, lo podrias lograr por triguer sobre esa tabla o por la aplicacion que le da mantenimiento a tu tabla de usuarios

[cadesa]

mmmmm, sera posible que me digas como hacer el trigger que me sugeris.

Gracias.

[jc3000]

Iniciado por kikolice

"al momento de crear un usuario en oracle se grabe la información en esta tabla, y que el usuario creado este asociado al registro de esta tabla"

eso no se puede, en dado caso lo puedes hacer al reves, cada que se registre/elimine un usuario en tu tabla se cree/elimine el usuario en la base de datos, lo podrias lograr por triguer sobre esa tabla o por la aplicacion que le da mantenimiento a tu tabla de usuarios

Es una pajilla mental, pero creo que si se podría. Tu puedes crear un trigger de BBDD que se dispare cada vez que se hace un DDL en la BBDD ¿ verdad ?, pues puedes preguntar si el tipo de ddl que se ha hecho es CREATE y si el tipo de objeto es USER. En caso afirmativo, haces una select sobre ALL / DBA_USERS para que recupere los datos que necesitas y los insertas en tu tabla de usuarios. Lo mismo se aplica para los DROP USER

Busca informacion sobre ora_sysevent,ora_dict_obj_owner y sys_context. Te será muy util.

[cadesa]

Gracias, voy a investigar a cerca de estos temas y a probar hacerlo.

[matanga]

Hola,

¿Todavia se sigue usando el modelo un usuarios de la aplicacion <--> un usuario de base de datos ?

jc3000, buen post.

Saludos

[cadesa]

Si se puede seguir usando para aplicaciones pequeñas que no tengan tanto trafico y que se quiera tener un mayor control sobre los usuarios, pero para aplicaciones con muchos usuarios (entiendase muchos usuarios un número mayor a 100) se puede realizar con el pool de conexiones de un programa de front end y con un solo usuario en la base de datos.

[jc3000]

Iniciado por matanga

Hola,

¿Todavia se sigue usando el modelo un usuarios de la aplicacion <--> un usuario de base de datos ?

jc3000, buen post.

Saludos

Gracias socio.

La unica vez que he visto eso fue en Meta4. Ahí los usuarios de aplicación son usuarios de BBDD, por lo menos cuando estuve trabajando con esa aplicacion ( llevaba la administracion de la BBDD, una 7.3 y de Meta4 ), no sé si ahora funcionará de igual manera.

Lo normal ( creo ) es que haya solo un usuario de BBDD y N usuarios de aplicacion, luego la propia aplicación gestiona los derechos, permisos etc etc de cada usuario.

Saludos

[kikolice]

Iniciado por jc3000

Es una pajilla mental, pero creo que si se podría. Tu puedes crear un trigger de BBDD que se dispare cada vez que se hace un DDL en la BBDD ¿ verdad ?, pues puedes preguntar si el tipo de ddl que se ha hecho es CREATE y si el tipo de objeto es USER. En caso afirmativo, haces una select sobre ALL / DBA_USERS para que recupere los datos que necesitas y los insertas en tu tabla de usuarios. Lo mismo se aplica para los DROP USER

Busca informacion sobre ora_sysevent,ora_dict_obj_owner y sys_context. Te será muy util.

tal vez se podria pero en mi opinion es complicarte mas la vida, en realidad es la aplicacion la que necesita la informacion en esa tabla, entonces que la misma aplicacion se encargue de la creacion y borrado de usuarios a nivel de base de datos

otra historia es si vale la pena mantener un esquema usuario aplicacion = usuario base de datos o que sea un usuario para todos y que lo controle la aplicacion, me voy por la primera

[jc3000]

No estoy de acuerdo, compañero.

Una aplicación ni tiene porqué, ni debe de hacer tareas de administracion de oracle tales como creación y mantenimiento de usuarios.

Para eso están las herramientas propias de Oracle. No digo que en algún caso muy, muy, muy excepcional se tenga que hacer así, aunque nunca lo he visto.

Repecto a lo de un usuario de BBDD por usuario de aplicación, puede ser muy util o puede ser una soberana cagada. Ya dije que cuando llevaba la administración de una 7.3 y Meta4 el tema era así : Usuario de aplicación = usuario de BBDD y la verdad es que funcionaba muy bien. Y ahora llevo una aplicación que es al reves: 1 usuario de BBDD por N usuarios de aplicacion y funciona igual que la otra : a las mil maravillas.

Creo que todo depende de la necesidad de cada sistema productor y la capacidad de gestionar permisos, roles, atribuciones para que cada usuario , ya sea de BBDD o de aplicacion solo haga lo que le corresponda hacer.

Por supuesto, puedo estar equivocado, pero esta es mi opinión.

Saludos

[cadesa]

Ya desviandonos un poco de la pregunta, yo creo como dije anteriormente que una aplicación se verá primero para cuantos usuarios va a ser, yo creo que entre menos usuarios tenga una aplicación es mejor tenerla usuario aplicacion = usuario BBDD (<100), pero si es una aplicación mayor se debera dejar con un pool de conexiones en el cual se administran los permisos de los usuarios y la base de datos no se sobrecarga, y es también bueno tener en ese caso N usuarios aplicacion = 1 usuario BBDD, los dos son utiles lo que ocurre es que en el primer caso si un usuario esta sobrecargando las peticiones del servidor se puede hacer killing en él y no afectar a los demás usuarios mientras que en el otro caso si hay un usuario que esta sobrecargando las peticiones entonces por ley se tendrán que eliminar todas las sesiones porque como solo hay un usuario de BBDD se afecta a todos los que trabajan.

Pero eso si es la opinion y la funcionalidad que se quiera para su sistema yo pienso que una aplicación de escritorio como la que yo estoy haciendo es mas facil manejarla 1-1 pero cuando ya es una aplicación web es mas facil manejarla N-1, y todo dependera de la arquitectura que se siga.

Saludos.

[kikolice]

Iniciado por jc3000

No estoy de acuerdo, compañero.

Una aplicación ni tiene porqué, ni debe de hacer tareas de administracion de oracle tales como creación y mantenimiento de usuarios.

Para eso están las herramientas propias de Oracle. No digo que en algún caso muy, muy, muy excepcional se tenga que hacer así, aunque nunca lo he visto.

en mi opinion es totalmente alreves, la aplicacion es la que se deberia de encargar de la administracion de usuarios, se tiene mas control sobre que puedes hacer usuario sin tener que acudir a una "herramienta propia de oracle" que en un entorno muy estricto, como el de un banco, ni siquiera el mismo administrador del sistema tiene acceso

[jc3000]

Opinión que respeto en lo que vale, pero que en este caso no comparto.
Pero esto está bien, cada uno expone sus puntos de vista sobre un tema y el que los lea, que saque sus conclusiones y obre en consecuencia.

Seguro que alguien saca cosas positivas de este hilo.

Saludos

[MutenRo]

Buenas,

en mi opinión lo ideal es tener tantos usuarios de BBDD como perfiles de usuario se necesiten en la aplicación. Ejemplo: una aplicación de historiales médicos a los que acceden auxiliares, enfermeros, médicos y administradores --> serían 4 usuarios, cada uno con sus permisos (y gestinonado por el DBA de turno, no el programador de la aplicación), pero por parte de la aplicación puede haber tantos usuarios de cada tipo como se quieran.

Por una parte el que haya pocos usuarios de BBDD facilita el mantenimiento de la BBDD y en cuanto a seguridad es mucho mejor que un solo usuario con el que todos accedan, debido a que si un auxiliar consiguiera por ejemplo (como fuera) su usuario y password de la BBDD sería sencillo conectarse sin utilizar la aplicación y tener acceso a todos los datos.

Por otra parte la aplicación podría gestionar todos los usuarios clasificándolos por perfil y realizando la conexión oportuna según el tipo. De esta manera si hay algún fallo de seguridad en la aplicación (bastante habitual) será la BBDD quien devuelva errores por falta de privilegios.

Un saludo.