FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Acceso exclusivo a usuarios
Hola amigos que tal. Buenas noches.
Necesito orientación. Se trata del acceso a la información exclusiva para ciertos usuarios PERTENECIENTES a una institucion en particular. Me explico: Tengo una aplicación a la cual pretendo que se conecten varias instituciones (Unidades Operativas), las cuales pueden ser: Hospitales, Casas de asistencia, Asilos de ancianos, Orfanatos, Guarderías infantiles y para adultos mayores, etc...etc.... Cada una de estas instituciones, registrara en mi aplicación, un padrón de personas que recibirían el producto que mi empresa les vende, registrando obviamente la institución que realiza el pedido mas los nombres de cada persona, entre otros datos de cada uno de ellos como la direccion y la fecha de nacimiento...... PROBLEMA: ¿Como mostrarle a cada institución en mi aplicación SOLO la información que está haya registrado y que no pueda ver la información de las demás instituciones? LO QUE ESTOY PENSANDO (Y no he hecho): Definir una tabla de usuarios a los cuales les registraré a que institución pertenecen, de tal manera que la PK de la tabla sería (por decir algo), USUARIO+CLAVE_ INSTITUCIÓN....y que cuando se conecten validar su clave de USUARIO y verificar si este usuario pertenece a la institución que él haya seleccionado en la pantalla de conexión...... ...Ahora, que opinan de esta idea?....Existe alguna mejor? y para los que tengan algo parecido....como lo tienen....es decir, como lo lograron (código por fa) Uso DELPHI 2010 y Firebird 1.5 No saben lo agradecido que estoy por su apoyo y orientación que le dediquen a mi consulta. Saludos muchachos.....
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#2
|
|||
|
|||
Hola
Yo no uso firebird ni he hecho un sistema como el que mencionas pero yo pondría un campo en la tabla de usuarios el ID de la institución y en el registro de personas el ID de la institución, a la hora de cualquier consulta solo debe coincidir ambos campos en ambas tablas. Saludos
__________________
Cancun, Q.Roo, México |
#3
|
||||
|
||||
Cita:
Asi como estás exponiendo tu caso das a entender que tu problema se trata más de diseño del sistema que algo propio a un problema duda en concreto con Firebird. Concretamente, tu duda es como encarar el problema desde el lado de la interfaz, o en como diseñar la estructura de la base de datos (que dará lo mismo sea el motor que sea)? ¿O ambas cosas? De lo que estoy seguro es que el que hayas elegido a Firebird como motor, es de sobra. En términos abstractos, y prácticos, en todo caso el diseño se lleva con un buen análisis y apoyándose en el uso de DER... que es algo independiente del motor. Que luego tu vuelques ese diseño y arquitectura en el motor en cuestión es por como has encarado el problema irrelevante. Explícate bien. Saludos, |
#4
|
||||
|
||||
Cita:
Aunque no sabemos si va a estar todo centralizado o ¿cómo? |
#5
|
||||
|
||||
Gracias casimiro
Gracias casimiro por tu respuesta. Efectivamente la base de datos estará centralizada y todos los usuarios de cada una de las instituciones (2 0 3 usuarios y no mas) se conectaran a la base de datos, ejecutando de manera local el EXE de la aplicación.
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#6
|
||||
|
||||
Pues entonces te vale lo dicho antes, en la BD debes de tener una tabla de instituciones y otra de usuarios de las instituciones, básicamente algo así:
|
#7
|
||||
|
||||
Coincido con tu propuesta
Cita:
Efectivamente coincido con lo que comentas, de hecho empezaré a realizar algunas pruebas con lo que comentas y les platico..... Se siguen recibiendo ideas ! Gracias a todos.
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#8
|
||||
|
||||
Cita:
No se trata del diseño de la interfaz, si no, de como controlar el acceso a la información de la base de datos por cada uno de los usuarios. Es decir....que la información q registren los usuarios de un hospital no la pueda ver los usuarios de un Asilo de ancianos o los usuarios de un Orfanato. Esto lo tengo bien claro que lo debo de controlar a nivel base de datos (Firebird), mi duda es....como hacerlo?....que ideas proponen? La que yo planteo al inicio del hilo, pudiera ser viable?... No sé sí ahora haya quedado mas claro para ti Delphius
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#9
|
||||
|
||||
Hola
USUARIO (nombre) + CLAVE (dato) + INSTITUCIÓN (dato) + ACTIVO (si/no) + ACCESO (numérico) Con esto se puede hacer. Saludos
__________________
Siempre Novato |
#10
|
||||
|
||||
mm?
Cita:
Duda: "CLAVE" (dato)....es la clave del usuario? y "ACCESO (numérico)" que vendria siendo?
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#11
|
||||
|
||||
Hola
Clave es la clave del usuario acceso es el nivel de acceso que tendra al programa, puede ser del 1 al 5 siendo 1 total. 2 a ciertos datos etc. Asi lo uso yo, cada usuario puede accesar a solo parte del programa asi se controla quien y que parte usa. Saludos
__________________
Siempre Novato |
#12
|
||||
|
||||
Ok, te agradezco por tu comentario.
De hecho me pase revisando el foro y estuve leyendo acerca de los niveles de acceso que mencionas, solo que me parece que los accesos vendrían siendo otra cosa aparte de lo que plantea mi duda, sin embargo es interesante ya que en algún momento talvez recurra a los accesos. Te comento q tengo pensado que todos los usuarios puedan consultar todo, pero no modificar o insertar registros de ciertas tablas, solo aquellas de SI deban (obvio). Talvez por ejemplo que no puedan modificar o insertar registros a los catálogos....por decir algo.
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#13
|
||||
|
||||
Hola
El problema que veo con el sistema que quieres implementar es que en todas las tablas tendras que poner tanto al usuario como la institucion. Lo mas sencillo seria una BD por institucion y un programa que las vea o cargue la que se quiera ver independientemente. Saludos
__________________
Siempre Novato |
#14
|
||||
|
||||
Aplicando el criterio que te han dado, tablas (instituciones y usuarios), en el resto de tablas de tu sistema debes incluir un campo "id institución", no es necesario que sea PK, como FK es suficiente. Este campo es el que te discrimina la información entre instituciones. Si consideras que el usuario debe ser discriminador, pues lo mismo. Ahora los trucos:
A) los usuarios también los creas en la BBDD, con ello consigues a través de trigger incluir el usuario y la institución, por la relación entre las tablas (institución y usuarios), sin necesidad de modificar la aplicación. B) en la aplicación, en las dataset principales, incluir la variable /* {id institución} */ tal y como he escrito. Esto será sustituido al vuelo en el evento Create por la condicion de la istitucion del usuario logeado. C) usar siempre claves únicas, las demás siempre FK. Tus tablas hijas y sobre todo tu lo agradecerás.
__________________
PepeLolo El hombre el único virus que mide más de unas cuantas micras |
#15
|
||||
|
||||
Cita:
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#16
|
|||
|
|||
Otra posible solución ...
mRoman:
A mi parecer, creo que tu problema lo puedes solucionar más fácilmente utilizando usuarios, roles y creando vistas actualizables con la opción "WITH CHECK OPTION". Te recomiendo, encarecidamente, que leas el siguiente libro: "La Cara Oculta de Delphi 4". Lo puedes encontrar en forma gratuita en formato PDF si haces una búsqueda a través de google (incluso creo que está en este mismo sitio). De hecho, a mi muy particular punto de vista, este libro debe de ser un referente obligado a cualquier programador de Delphi y que además utiliza Interbase o Firebird como su motor de base de datos. Saludos, Gerardo Suárez Trejo P.D. "No eches en saco roto" esta pequeña recomendación (solo porque pienses que ahora estás utilizando Delphi 2010), créeme que la mayor cantidad de conceptos, tanto en Delphi como en Interbase 1.5 y Firebird siguen aun vigentes. |
#17
|
||||
|
||||
Lo mejor de lo mejor para delphi + bases de datos: la cara oculta de delphi
"No se puede" ser un experto sin antes haber leido ese libro. |
#18
|
|||
|
|||
Mejor leer la La Cara OCulta de Delphi 6 generosamente ofrecido a la comunidad por Ian Marteens. La mayoría de los capítulos siguen siendo muy validos al dia de hoy.
__________________
Luis Fernando Buelvas T. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Controlar acceso a Usuarios | luxus | Varios | 4 | 13-06-2008 07:55:09 |
Acceso por miles de usuarios simultaneo | HomeCinema | Firebird e Interbase | 0 | 06-02-2007 10:38:23 |
acceso simultaneo varios usuarios Tabla interbase | hibero | Conexión con bases de datos | 15 | 03-12-2006 23:21:16 |
Protección de acceso a usuarios | jasensio | Seguridad | 1 | 02-10-2006 13:45:59 |
permiso de acceso a usuarios | jzginez | Firebird e Interbase | 6 | 06-10-2003 14:28:18 |
|