Acceso exclusivo a usuarios

[[Delphius]]

Empezado por mRoman

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.

Si en tu diseño de la base de datos haz hecho una formal y explícita relación entre las instituciones y los productos que éstas tienen entonces todo se resume a hacer una consulta filtrada (es decir con WHERE algo) para obtener exactamente los productos que pertenecen a una institución.

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,

[mRoman]

Empezado por Delphius

Si en tu diseño de la base de datos haz hecho una formal y explícita relación entre las instituciones y los productos que éstas tienen entonces todo se resume a hacer una consulta filtrada (es decir con WHERE algo) para obtener exactamente los productos que pertenecen a una institución.

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,

Gracias Delphius por tus comentarios....en realidad creo que varios de nosotros que posteamos en este foro, en algún momento experimentamos o sentimos q estamos en "pañales"....claro dependiendo del nivel del sistema que querramos desarrollar y que dependiendo de ello escasamente posteamos....y sí es el caso (de no postear para preguntar) nos convertimos entonces en personas con mayor conocimiento que orientamos a personas como yo....sinceramente te agradezco.

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