Crear Usuarios en Firebird
 

Hola a todos...???

Quiero hacerles una consulta sobre cual es la manera correcta de trabajar... y porque es la correcta...

En mi caso particular... cuando tengo una aplicación que es ocupada por varios usuarios, cada usuario se logea contra la aplicación ingresando usuario y contraseña, pero el usuario que ingresa a la base de de datos siempre es el mismo "sysdba"...

Entonces me he estado preguntando si esta forma de trabajar es la correcta... Que sin duda creo que no sino firebird no tendría la posibilidad de crear usuarios....

Como puedo sacar mas beneficio teniendo los usuarios en el servidor Firebird???

Saluda Atte Neeruu!!! :)

Siempre he usado sysdba, ¿por qué?, pues seguramente por comodidad y porque me parece más funcional tener una tabla de usuarios con los campos que necesites en cada ocasión.

Hola.

Yo al igual que casimiro uso una tabla de usuarios que no es la de la base de datos. Usando los usuarios de la base de datos puedes controlar ciertas funcionalidades como que te permita insertar, borrar o modificar registros usando las excepciones de la base de datos pero creo que no mucho más (si me equivoco que alguien me corrija).

Con una tabla para los usuarios puedes especificar en qué partes del programa quieres que entren, si hay ciertos campos que pueden visualizar/modificar o no, etc. pero claro, ya todo esto tiene que ser por código.

Imagino que dependiendo el uso que le vayas a dar te interesará más una forma u otra.

Saludos

Efectivamente; con los usuarios a nivel de bases de datos se puede controlar el acceso, y uso, de los elementos de una base de datos.
Y con usuarios dentro de la base de datos se pueden implementar controles a nivel de sistema.

Existen, y es posible de esperar, situaciones intermedias o mixtas. Por ejemplo disponer del usuario SYSDBA para únicamente el rol de DBA y el desarrollador y además definir ROLES y USUARIOS específicos para otros usos restringidos o limitados que luego la aplicación utiliza convenientemente.
Naturalmente esto es más complicado de encarar y también tiene sus pros y contras pero de que se puede hacer, se puede.

Saludos,

Crear Usuarios en Firebird Reply to Thread
 

Hola a todos.... gracias por sus respuestas...

Por lo que leo, trabajar siempre con el sysdba no esta mal....

Si utilizo los usuarios en una tabla de mi base de datos pierdo la información que puedo recuperar con programas como Sinática Monitor o InterBase Performance Monitor, debido a que siempre es el mismo usuario el que se logea...

Ahora estoy analizando la posibilidad de seguir manejando los usuarios en una tabla de mi base de datos, pero crearlos en firebird... de esta manera puedo obtener información sobre el uso de la debe según el usuario.

Que opinan sobre eso??? Es un pensamiento correcto o no???

Saluda Atte Neeruu!!!:)

No puedo decir que alguno sea incorrecto, pero si puedo decir que todas las opciones que barajes son correctas. Correctas en cuanto logren responder a los requisitos y funcionalidades estudiadas.

No necesariamente por hacer algo de una forma de otra lo hace más o menos correcto.
Lo importante es que te atengas a lo que se necesita, y respete a alguna posible normativa, restricción técnica-operativa y/o legal. En cómo llegues luego a eso es de menos.

Saludos,

Crear Usuarios en Firebird
 

Se que hay muchos caminos para llegar a un mismo destino....

Yo busco sus consejos para elegir el camino mas profesional.... Y no estoy del todo de acuerdo con:
Creo que porque las cosas anden, no significan que estén realizadas de una forma correcta...



Y volviendo al tema, entonces no hay una forma correcta o incorrecta de trabajar con los usuarios sobre Firebird, es mas por lo leído en el Post, todos trabajan con "sysdba"...


Saluda Atte Neeruu!!! :)

Creo que no se me entendió.
Es que cada opción tendrá sus pros y contras... y elegir una opción no hará de la otra; necesariamente, una mala alternativa que se pueda desechar ni tomar en cuenta en alguna otra ocasión. Todo dependerá de lo que realmente necesites, de los requisitos, y posibles restricciones. De allí en más es una cuestión que pasa por el análisis, y la astucia, que lleve a cabo el analista y programador.

Voy a poner un ejemplo, necesito mantener ordenado 1000 registros. Algoritmos de ordenamiento hay a roletes... la clásica elección y por la que se van la mayoría es QuickSort. Pues, QuickSort podrá ser muy rápido... pero no siempre es lo más conveniente. Hay situaciones que ameritan otros enfoques, podría ser que para el contexto en estudio sería más apropiado TimSort (un nuevo algoritmo que es mucho más rápido que QuickSort, pero que aplica a otras situaciones). La pregunta es ¿Esto hace de QuickSort que sea un pésimo algoritmo? ¿TimSort es el nuevo rey y lo debemos utilizar siempre? En las nuevas versiones de algunos lenguajes es el algoritmo por defecto; por ejemplo Phyton y Java ya lo implementan.

Lo que parece correcto ahora, puede que no lo sea mañana. No esperes que exista una única, y última, respuesta que sea la más profesional y acabe con cualquier mal.
Podrán andar bien ahora, quizá luego no... o si... No se puede asegurar. Lo máximo que podemos hacer es considerar en la mesa muchos factores, sopesarlos y luego esperar que esa elección sea la más adecuada mientras el contexto se mantenga.

Aquí tu sólo te limitaste a ofrecer muy pocos elementos y esperas a una respuesta mágica. Cada profesional tiene sus trucos, sus propios diseños, sus propias mañas, su propia experiencia. Es de esperar que no exista un único diseño... entiéndelo.

Ya lo dije... la respuesta mágica es DEPENDE. Ahora si insistes en una respuesta sólida prepárate: Mientras TU dudes, TU diseño será débil. Si no estás seguro de tus elecciones, de tu diseño, de tu análisis, de tu propuesta, no lograrás encontrarte en equilibrio y tu sistema tambaleará cada vez que pase por tu cabeza un "Y si", "No será que". Cuando te sientas cómodo con tu elección, recién lograrás encontrar una respuesta. El aprendizaje luego te llevará a preguntarte de nuevo si fue lo correcto, o en donde se puede mejorar.

Es preferible, y más digerible, hacer un sistema que vaya madurando con el tiempo que un sistema nazca maduro instantáneamente.

Exacto. Los usuarios y roles están para ser usados... cómo lo uses dependerá de tus instintos y en cada proyecto en que te embarques.

Momento... ¿en que lugar se ha dicho que TODOS trabajamos con SYSDBA unicamente? No generalices.

Saludos,

Suscribo lo que ha dicho delphius. Todo depende.

Yo por ejemplo, sí me límito a utilizar los usuarios de Firebird. Consultar los privilegíos de forma nativa es un lío, por eso desarrollé una API para consultarlos de manera fácil y sencilla. La API está acá en el FTP del club. Creo que con esta API encontrarás un poco más fácil consultar los privilegíos de usuarios nativos que inclusive consultar mediantes continuos SELECT's privilegios virtuales.

Ahora, por qué elegí trabajar con lcuentas nativas y no crear una tabla para manejar mis propios usuarios virtuales a cómo muchos acostumbran? Por qué considero que era más seguro. Además podía utilizar la variable CURRENT_USER (necesitaba utilizarla frecuentemente). Otra cosa es que no quería que mis clientes compartieran su clave de SYSDBA o cualquier usuario con todos los privilegios sobre la DB solo para hacer la configuración de la base de datos.

Siempre hay sus pros y sus contras en ambos casos. Por ejemplo, si utilizas usuarios nativos no los puedes facilmente si cambias de servidor a cómo lo harías con usuarios "virtuales". Además, no sé cómo se comportaría el servidor con varios cientos de usuarios o más. No creo que sea una gran penalidad, pero no me gusta dar las cosas por sentado.

Lo principal es que evalues. Talvez tengas dudas del por qué o el NO por qué elegir una arquitectura o la otra. Talvez quieras compartir estas dudas para escuchar nuestras opiniones.

Saludos!