Crear Usuarios en Firebird

[Neeruu]

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:

"Correctas en cuanto logren responder a los requisitos y funcionalidades estudiadas."

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!!!

[[Delphius]]

Empezado por Neeruu

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...

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.

Empezado por Neeruu

Y volviendo al tema, entonces no hay una forma correcta o incorrecta de trabajar con los usuarios sobre Firebird,

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.

Empezado por Neeruu

es mas por lo leído en el Post, todos trabajan con "sysdba"...
Saluda Atte Neeruu!!!

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

Saludos,

[[Chris]]

Empezado por Delphius

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.

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!