Acceso exclusivo a usuarios

[[Delphius]]

Empezado por mRoman

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

Pues yo no entiendo... ¿Y que tiene que ver el motor de base de datos, en este caso Firebird, con tu duda?
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,

[Casimiro Noteví]

Empezado por Delphius

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?

Pues eso, una tabla de instituciones, otra de usuarios de las instituciones y ya está solucionado el problema.
Aunque no sabemos si va a estar todo centralizado o ¿cómo?

[mRoman]

Empezado por Casimiro Notevi

Pues eso, una tabla de instituciones, otra de usuarios de las instituciones y ya está solucionado el problema.
Aunque no sabemos si va a estar todo centralizado o ¿cómo?

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.

[Casimiro Noteví]

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í:

Código SQL [-]
tabla tbInstituciones (
  id integer not null,
  nombre varchar(64),
  ...
  primary key (id)
)

tabla tbUsuarios (
  id integer not null,
  id_institucion integer not null,  /* esta es la institución al que pertenece el usuario */
  nombre varchar(64),
  password varchar(64),
  ...
  primary key (id),
  foreign key (id_institucion) references tbInstituciones (id)  /* clave foránea a la tabla tbInstituciones */
)

[mRoman]

Empezado por Casimiro Notevi

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í:

Código SQL [-]
tabla tbInstituciones (
  id integer not null,
  nombre varchar(64),
  ...
  primary key (id)
)

tabla tbUsuarios (
  id integer not null,
  id_institucion integer not null,  /* esta es la institución al que pertenece el usuario */
  nombre varchar(64),
  password varchar(64),
  ...
  primary key (id),
  foreign key (id_institucion) references tbInstituciones (id)  /* clave foránea a la tabla tbInstituciones */
)

Te agradezco casimiro por tu tiempo y respuesta.

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.

[Casimiro Noteví]

Empezado por mRoman

Efectivamente coincido con lo que comentas, de hecho empezaré a realizar algunas pruebas con lo que comentas y les platico.

No, no... ¡¡¡error!!!, así no se diseña un sistema, supongo que lo habrás estudiado.

1. Primero tienes que saber exactamente qué se quiere hacer y controlar. Cosa que veo que no tienes claro.
2. Luego tienes que pensar en cómo hacerlo. Cosa que veo que lo tienes menos claro que lo anterior.
3. Después tienes que escribir (papel y lápiz) cómo será todo lo anterior (pasarlo de la cabeza al papel). Imposible hacerlo si no has pasado por los pasos anteriores.
4. Finalmente, con lo anterior ya hecho, y todo totalmente claro, es cuando hay que implementarlo en código.

Saltarse uno de los pasos no es viable.

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

[mRoman]

Empezado por Casimiro Notevi

No, no... ¡¡¡error!!!, así no se diseña un sistema, supongo que lo habrás estudiado.

1. Primero tienes que saber exactamente qué se quiere hacer y controlar. Cosa que veo que no tienes claro.
2. Luego tienes que pensar en cómo hacerlo. Cosa que veo que lo tienes menos claro que lo anterior.
3. Después tienes que escribir (papel y lápiz) cómo será todo lo anterior (pasarlo de la cabeza al papel). Imposible hacerlo si no has pasado por los pasos anteriores.
4. Finalmente, con lo anterior ya hecho, y todo totalmente claro, es cuando hay que implementarlo en código.

Saltarse uno de los pasos no es viable.

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

Agradezco tu comentario Casimiro. Cuando comento que pondré en práctica lo que me dices....me estaba refiriendo a "pensar" para luego pasar al "papel" y de ahi todo los demas....asi como dices en tu pasos enumarados.

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

[mRoman]

Empezado por Delphius

Pues yo no entiendo... ¿Y que tiene que ver el motor de base de datos, en este caso Firebird, con tu duda?
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,

Antes que nada gracias Delphius por contestar.

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