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