Problema con tablas.

[Karen_mBrK]

Buenos días amigos.

Mi problema es el siguiente: Tengo una tabla llamada login y otra llamada usuarios.
El campo en común entre ambas es 'CURP' con la tabla login es con la que se compara mi acceso hecho en PHP, pero la que tiene la primary key es la tabla Usuarios, si no doy de alta mis usuarios primero en 'Usuarios' no puedo darles password y usuario para loguearse, en fin, hasta aquí todo bien.

La cosa es que creé otra tabla que se llama "Usuarios_R" que igualmente contiene una primary key, y está de igual manera enlazada a la tabla 'Login' el problema está que aunque mi tabla 'Usuarios_R' me deja dar de alta usuarios, a la hora de ingresarlos en mi tabla login, no me deja, y me sale el siguiente error: "Cannot add or update a child row: a foreign key constraint fails"
Incluso intentè invirtiendo las llaves, vaciando todas las tablas, quitar y poner llaves, y volverlas a llenar, pero nada.

Se me ocurriò tambièn que era probable que 'chocaran' por el campo CURP que todas ellas tienen en común, así que cambié la llave foranea que conecta 'Usuarios_R' con 'Login' pero me sigue sin funcionar.

Espero y e puedan ayudar, gracias.

[gnzsoloyo]

Da la impresión de que estás creando las tablas al "tun-tun", como se dice por acá. Es decir, las estás creando sin analizar debidamente. No puedes apuntar una misma FK de una tabla a dos tablas diferentes. Eso es un error, por lo que espero no lo estés haciendo así.
Por un lado, es lógico que no puedas registrar logueos de usuarios que no existen, por lo que el usuario debe estar en la tabla Usuarios antes de eso. Lo que no tiene mucha utilidad es crear una tabla independiente para registrar el passwiord desde el momento en que en un sistema, un mismo usuario sólo puede tener un único username y cada username un único password. Pero tu estas creando una tabla que no se entiende.
Empecemos por el lo que parece ser el problema: ¿Qué representa "Usuarios_R"?
Luego de eso, ¿Qué es un Usuario? ¿Una persona o un user del sistema?

[Karen_mBrK]

Ok, tengo un portal por el que todos los usuarios deben ser capaces de ingresar con sus respectivos Users y passwords, lo que sucede es que diferentes "clientes" con distintos datos necesitan entrar al portal, así que pensé que todos ellos lo único que deben compartir es la tabla de 'Login' a la cual apunta directamente mi Index, así que para el 'Cliente X' creé la tabla 'Usuarios' que contiene 9 campos, y para el 'CLiente Y' creé la tabla 'Usuarios_R' que contiene 17 campos.

[gnzsoloyo]

¿Estás creando diferentes tablas para categorías de clientes, pero apuntando a la misma PK?
Tienes un error de diseño de datos, y más exactamente de modelado. Me parece que tienes que hacer una mejor abstracción de las entidades.
- Tienes Usuarios, que son todos los usuarios, sin importar de qué categoría. En esa entidad tienes atributos tales como username (que es PK), password, fecha_alta, fecha_baja y posiblemente categoria_id, que te permita separar clientes, proveedores (si corresponde), usuarios internos, administrativos, DBA, syadm, etc.
- A partir de allí puedes crear las diferentes entides Cliente, Proveedor, UsuarioIntenro, por ejemplo, todas apuntando al ID de Usuario, habitualmente el username, o bien un ID_usuario que se quiera usar.
- La tabla de Login sólo debe ser un registro de actividades, es decir, cada vvez que se loguea, se registra el id del usuario, la fecha y hora de acceso, y la de deslogueo, si se puede.
- Puede existir una tabla de Permisos, relacionada con Usuario, para identificar todos los permisos de acceso a la aplicación con que cuente el usuario.
- Si tienes más de una categoría de cliente, eso puede implicar un esquema de herencia, donde tengas una entidad base Cliente y entidades hijas Cliente_TipoA, ClientetipoB, etc. Estas hijas no tienen una PK propia, sino que heredan la PK de la entidad superior, la que al mismo tiempo es FK de esa, y PK de la propia tabla de tipo de cliente.
Adicionalmente, cuando tienes dos tipos de usuario con diferent cantidd de atributos, hay que ver cuáles son los atributos comunes. Esos van en la entidad superior (Cliente), y sólo la PK/FK y los propios van en las entidades hijas.¿Se va entendiendo?

Este tipo de esquemas relacionales exige que se respeten las dependencias funcioanles al dar las altas. Esto implica que si tienes dos o mas tipos de cliente, se deben dar de alta como cliente antes de registrarlo en el subtipo (que por otro lado es logico desde el momento en que necesitas la PK de Cliente).
Por otro lado, hay que tener cuidado en no generar dependencias circulares, ni tratar de conectar todo con todo porque si. Existen reglas para todo esto.

te sugiero que uses una herramienta de diseño como el MySQL Workbench para seguir el desarollo de la base. Verlo gráficamente te permitirá evitar errores.
-

[Karen_mBrK]

Tengo una tabla de permisos, al hacer el login, en base a que tipo de usuario eres te deja o no acceder a algunos lugares.

Tienes razón, estaba apuntando una misma llave foranea a dos tablas distintas, por lo que asigné una nueva (ahora login tiene ahora 2 llaves foraneas una apunta a Usuarios y la otra a Usuarios_R)

Pero me sigue no dejando insertar datos a login, que ya están dados de alta en usuarios_r. Y es que, en realidad pienso que necesito ambas tablas, por la diferencia de campos, ya que si estos fueran iguales, simplemente compartiría la tabla, aunque no me pareciera lo más oportuno, debido a que pertenecen a distintos clientes.

[gnzsoloyo]

Pero me sigue no dejando insertar datos a login, que ya están dados de alta en usuarios_r. Y es que, en realidad pienso que necesito ambas tablas, por la diferencia de campos, ya que si estos fueran iguales, simplemente compartiría la tabla, aunque no me pareciera lo más oportuno, debido a que pertenecen a distintos clientes.

Que pertenezcan a diferentes clientes no implica que no puedan comaprtir tabla. Estás pensando en procesos, no en datos. No se trata de la misma lógica.
En BBDD, se modela en base a la entidad a representar, no en base a los procesos donde se usa. Si dos entidades (clientes) tienen diferentes cantidades de atributos, pero un conjunto de esos atributos refiere a los mismos dominios (qué representan), lo que se hace es modelarlas como relaciones padre / hijo, como te dije. Que luego lo uses en la aplicación para uno u otro cliente, es un tema procedimiental, no de abstracción de datos.
Me resulta difícil explicartelo con un ejemplo útil si no nos das una descripción de las columnas que tienen esas tablas. Necesitamos verlas para poder ejemplificartelo.

Probablemente una idea sería en Argentina hablar de personas físicas y personas jurídicas. AMbas son persona, pero la idenitdad impositiva es diferente. Aún así comparten algunos atributos (Nombre, calle, numero, departamento, ciudad, provincia, país), pero otros sólo lo tienen unos y otros no (CUIT / DNI, Apellido / Razon Social).
Pero siguen teniento un solo identificador en el modleo de datos como cliente. El resto es un tema de herencia.

[Karen_mBrK]

Tienes razón, no veo el porque no puedan compartir tabla, y más porque lo 9 campos que tengo en "Usuarios" son los mismos de "Usarios_R" pero la diferencia es que esta última tiene 8 campos más, ¿Crees que en vez de tener usuarios_r, solo debo crear una tabla con los campos que me hacen falta en usuarios, y ligarlos, o heredarlos, como quieras decirle, en base a su campo en común?


En todo caso, agradezco mucho tus opiniones

[gnzsoloyo]

¿Podrías postear la lista de campos de cada tabla, y cuál sería la definicion que usas para determinar el tipo de cliente?
Sería más fácil darte una idea de normlaización si sabemos con qué atributos estás trabajando.

[Karen_mBrK]

Mi tabla usuario contiene estos campos:

CURP | NOMBRE | PATERNO | MATERNO | RFC | IMSS | TELPER | CEL | MAIL | FECHA_INICIO | DOMICILIO | CLIENTE

Y la que se supone que tendría que ser Usuarios_R son estos, si bien no son tantos campos que me hacen falta, me sobra "Cliente" de la tabla usuarios, que no aplica para la tabla r:

CURP | NOMBRE | PATERNO | MATERNO | RFC | IMSS | TELPER | CEL | MAIL | FECHA_INICIO | DOMICILIO | REGION | ZONA | PUESTO | PLAZA

¿cuál sería la definicion que usas para determinar el tipo de cliente?

Yo no defino el tipo de cliente, es dependiendo al proyecto al que pertenezcan. Empecé con 1 solo proyecto, pero después me dijeron que sobre la misma DB y el mismo sitio en PHP, debía agregar este nuevo proyecto, y después se piensan adaptar otros 2 proyectos sobre lo mismo, con excepción de algunas diferencias, justo como ahora.