Indices NULL

[axelb]

Buenas tardes, estoy haciendo un sistema y en una parte de el, hay que cargar una especie de ticket, esos tickets pueden estar relacionados a una planilla o no. Al momento de crear la tabla en donde voy a guardar los tickets agrego un campo llamado numPlanilla, lo defino como un indice (la planilla debe estar previamente cargada) y tmbn permito que sea nulo. Hasta acá todo bien, pero el problema apareció cuando intento cargar un ticket sin numPlanilla. Me devuelve un error con el indice "Cannot add or update a child row: a foreign key constraint fails", al consultar con mi socio me dice que lo que pretendía hacer no era posible y que para no perder tiempo elimine el indice, si de todas formas, el numero de planilla es elegido por el usuario, y siempre va a ser uno que exista. El inconveniente con esto es que si se quiere eliminar la planilla, se va a eliminar sin problemas, y los tickets asociados a la misma quedarían inconsistentes.

Mi pregunta es, ¿se puede definir un indice como nulo en mysql? Si es asi, ¿será que el valor que recibe numPlanilla no es null? o ¿por qué recibo este error entonces?

[gnzsoloyo]

Un NULL es un no-dato, es un estado de indeterminación y por consecuencia no peude ser manipulado como información.
No existen los índices que puedan aceptar claves NULL, por la simple razónn de lo que te dije: un NULL es algo que no existe, y no se puede indexar las inexistencias...

Por otro lado, el mensaje de error que mencionas:

Cannot add or update a child row: a foreign key constraint fails

no es un error exactamente por una falla de índice. Es algo más grave: Una violación a la integridad referencial de la tabla, es decir que estás intentando ingresar en un campo un valor que no existe en la tabla a la que hace referencia.
SI el "indice" del que hablas, es una FK, puede apuntar a una clave de otra tabla que no sea PK, si esa clave es UNIQUE. En ese caso el campo que es FK podría ser NULL, pero si y sólo si en la tabla referida hay un único registro donde el campo indexado como UNIQUE es NULL.

¿Se entiende?

En esencia, tu problema es que estás diseñando MAL el sistema. Existen muchas alternativas para lograr lo que deseas, pero en todas ellas deberás respetar la integridad referencial cuando hay FK.
Tal vez haya como lograr lo que quieres, pero deberíamos entender completamente tu sistema apra proponerte una solución.

[axelb]

uf me maree un poco!!

en la practica funciona de la siguiente manera: Se carga una planilla que representa el trabajo de todo un dia, la materia prima generada en todo un dia. Esa materia prima se envia a otra empresa y esta devuelve tickets con los kilos llevados. 1 planilla > 20kg, 4 tickets > 20kg, cada tickets d 5kg aprox.
Esos 4 tickets "representan" a esa planilla, si bien los kilos pueden varias en pequeñas cantidades, dependiendo de como esten calibradas las basculas utilizadas.

Hasta aca todo bien, pero hay una excepción. Un grupo de personas trabaja generando materia prima de otra forma, y no utiliza dicha planilla. pero los tickets siguen estando y de la misma forma.

Entonces a nivel sistema, registramos 1 planilla (perteneciente a un grupo de personas) con 20kg, y luego se cargan esos 4 tickets, asignandolos a la planilla. Esto en las situaciones normales.
En la excepción, solo se cargan los tickets devueltos x dicha empresa, sin la planilla.

La tabla de tickets contiene el numero de ticket, los kilos brutos, si hubo algun descuento, el neto recibido, y el numero de la planilla que deberia estar cargada previamente.

Se entiende?

[gnzsoloyo]

OK. Expresemos entonces la información como reglas de negocio básicas:

- La producción de una empresa se registra por medio de Planillas.
- Cada planilla se relaciona con la produccion en Kg. (pertenecen a una empresa que denominaremos "Productor").
- La producción se envía a otra empresa (la denominaremos "Procesador"), que la procesa, que devuelve información de los kilos que recibe en cada envío (asumo que un ticket es un envio).
- Cada planilla se completa con un envío de 20 Kg en total, repartidos en tickets de hasta 5 Kg cada uno.
- El peso total se redondea, dado que el pesaje puede variar dependiendo del dispositivo usado (no queda claro el margen de variación o si es relevante).
- Parte indeterminada de producción procesada por la segunda empresa se relaciona con tickets, pero estos no se asocian a planillas, sino que representan reportes de produccion directa.

Bueno, en principio, hay más de una forma de modelar un esquema de BBDD consistente.
1) Puedes forzar la creacion de una planilla general, de modo de mantener consistente la relación entre planillas y tickets. Habría que analizar qué condiciones se deben cumplir por dependencias en las planillas para posibilitar la creacion de ésta. Si la planilla tiene relacion con un cliente (productor) registrado en otra tabla, posiblemente esto se pued hacer con un cliente genérico.
2) Puedes modelar a la inversa, es decir relacionar los tickets directamente a Productor y Procesador, y crear una tabla Planilla que se relacione con estos tickets si se corresponden a una. El problema es que requeriría crear una tercera tabla que relacione ambas cosas, por ejemplo Ticket_Planilla
3) Puedes modelar la relación como una generalización, donde una tabla Procesador herede a Planilla y a otra entidad que podemos llamar ProcesadosPorTicket, de donde colgarían los tickets, por ejemplo. Eso posiblemente requiera cambios grandes en el diseño del sistema, y consultas mas elaboradas, aunque también agregaría trazabilidad.

Estas son tres ideas al vuelo. Puede que haya muchas mas soluciones.

Personalmente me decantaría por la primera: Forzar la creación de una Planilla y asociarla a los tickets, cumpliendo con las restricciones que posea la planilla en otras tablas con el uso de entidades genéricas (clientes genéricos, responsables genéricos, etc), que me permitan dar el alta del registro de la planilla sin romper la integridad referencial.

Lo que te debe quedar en claro en esto es que tu, como analista funcional, tienes que proponer una solución, cuando lo que el cliente/usuario te aporta no alcanza para construir una con lo que ya existe.
Queda en ti plantearlo de forma convincente y que lo acepten.

[axelb]

Gracias gnzsoloyo! Me he replanteado la situación y he creado la tabla ticketPlanilla para este caso y esto también me sirvió para cambiar otra tabla que tenia con un caso similar.

Saludos y nuevamente gracias a este excelente foro y su gente!!

[axelb]

Ahora resulta que el ticket si no va relacionado a una planilla, debe tener la parcela en la que se ha trabajado. Entonces se debo crear otra tabla ticketParcela, no? o hay otra forma de resolver esto? quedaria la tabla ticket, la tabla ticketPlanilla y la tabla ticketParcela. Seria lo mejor, no?

[gnzsoloyo]

Bueno, allí hay un componente del que aun no se había hablado: ¿Qué se supone que es una parcela, y qué atributos (datos propios) posee? ¿Con qué se relaciona y de qué forma?

[axelb]

1 empresa -> N lotes
1 lote -> N parcelas
1 parcela -> N cuadros
1 cuadro -> N productos

El lote es una porcion de tierra, medida en metros cuadrados. Los lotes se sub-dividen en parcelas y estas a su vez en cuadros para las cuestiones mas especificas. La parcela en si no tiene datos propios.

El ticket si esta relcionado a una planilla ya posee una parcela que esta en dicha planilla, es por eso que si el ticket no es asignado a una planilla, debe especificarse el lote de donde proviene.

[axelb]

alguna respuesta?? :/