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
|
||||
|
||||
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 !! |
#8
|
||||
|
||||
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 !! |
#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
|
||||
|
||||
Cita:
Tu forma de hacerlo, tal y como has dicho antes es: ¡¡¡empezar a poner ladrillos sin saber ni dónde, ni por qué, ni cómo!!!, primero necesitas los planos hechos por el arquitecto, y en este caso tú eres el arquitecto, salvo que tengas un analista en tu empresa, después son los albañiles/programadores (con el seguimiento del arquitecto) los que ponen los ladrillos y echan el cemento, ¡¡¡pero siguiendo los planos que hizo el arquitecto/analista!!! |
#13
|
||||
|
||||
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 !! |
#14
|
||||
|
||||
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 |
#15
|
||||
|
||||
Cita:
En estos momentos estoy en la etapa del análisis....."imaginandome" como debo hacerle para que los usuarios solo vean su información....todavia no estoy con las tablas....de hecho tengo poco con el inicio de este aplicación si acaso 15 o 20 dias....
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#16
|
||||
|
||||
..........
|
#17
|
||||
|
||||
Cita:
Ahora por otro lado, tienes una falla conceptual que posiblemente será de problemas más adelante: tu error en confundir y mezclar usuarios e instituciones. Una cosa son los usuarios (mejor dicho, personal) de cada institución... y otra distinta es que cada institución sea y actúe como "usuario" de tu aplicación. Si te lees bien te enterarás de que haz mezclado ambas cosas. Cuando un "usuario" accede a su cuenta, no debiera determinar a que institución pertenece... Se supone que existe una relación formada entre las hipotéticas tablas usuarios e instituciones (relación muchos a uno, para ser precisos). De modo con el simple hecho de haber accedido debiera ser posible determinar a que institución representa. Cosa que se puede hacer y saber simplemente leyendo la clave foránea que apunta a la tabla instuciones. Ya con este valor una consulta del tipo select * from instituciones where ID = ClaveForaneaLeida basta para saber los datos de la misma. Como representante de su institución, ahora debe ser capaz de trabajar como si fuera una institución por tanto todo movimiento y operatoria que haga este usuario en realidad se debe hacer como si la institución hiciera estas operaciones. Por tanto aquellas tablas o entidades sensibles a tener relación o interés de registrar alguna información relevante sobre la institución deberá contar con un campo que formalice esta relación. Léase: clave foránea hacia ésta. Si no entiendes esto, me temo que estás muy en pañales y tienes una gran deficiencia y falta de conocimientos como para levar a cabo a buen puerto el sistema. Eso o simplemente te piensas que un sistema se hace por arte de magia y sin un debido análisis... tal como lo ha dejado en claro Casimiro. "Pierde el tiempo" en estudiar las cosas, analiza la situación. Saludos, Última edición por Delphius fecha: 07-10-2012 a las 19:37:24. |
#18
|
||||
|
||||
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 |
#19
|
||||
|
||||
Te agradezco tu orientación
Cita:
En cuanto a lo que me comentas, estoy iniciando con el análisis y estoy viendo que opciones existen de algo que (claro esta) no se del todo. En cuanto a la confusión que dice q tengo, pues te diré que yo lo conceptualizo asi....a cada institución la tomaré como un usuario los cuales podrán ser 1 o 2 0 3.....esto sí se quiere controlar qué usuario realiza movimientos (el cual no le interesa a mi empresa saber) por lo tanto, la institución podrá decirle a la persona encargada de alimentar al sistema, cual es el usuario y el obviamente el pass para accesar al sistema, como podrá ser cualquier otra persona a quien se lo diga...es decir no importa si JUAN, PEDRO o CHEPE entra al sistema con la misma clave de usuario. También sé que los sistemas no se hacen por "arte de magia" (aunque a veces Delphi me hace dudar sobre esto)...es largo el camino para llegar al final, que es la implementación del sistema. Gracias por tu tiempo y tus comentarios.....creeme q no los "hechare en saco roto" (como se dice en México). Saludos
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#20
|
||||
|
||||
Cita:
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
|
|
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 |
|