[Php-avanzado] Tablas de Bibliotech

[Leonardo Tadei - Pegasus Tech Supply]

Hola Pehuén,

El sáb, 28-12-2013 a las 23:14 -0300, Fernando Pehuén Borsani escribió:
> Hola profe!
> 
> Muchas gracias por la respuesta pronta. Ya entendí a lo que se refería con
> "dato vivo".
> 
> Cambio el ejemplo de las tablas para que mi duda sea compatible con el
> problema a resolver.

	Veamos:

> Supongamos que tengo una relación de este tipo:
> ----------------
> UNIDADES
> Id / id_libro / código_interno
> 
> PRESTAMOS
> Id / id_unidades / id_asociado / fecha_prestado / fecha_vencimiento
> ----------------

	Nota al margen: es más correcto el nombre del campo id_unidad en vez de
id_unidades.

> Para evitar inconsistencias al borrar unidades debería hacer:
> (Opción 1)
> ----------------
> UNIDADES
> Id / id_libro / código_interno
>  
> PRESTAMOS
> Id / id_unidades / id_asociado / fecha_prestado / fecha_vencimiento /
> editorial / genero / codigo / titulo / portada / resumen
>  ----------------
> 
> O alcanzaría con:
> (Opción 2)
>  -----------------
>  UNIDADES
> Id / id_libro / código_interno
>  
> PRESTAMOS
> Id / id_unidades / id_asociado / fecha_prestado / fecha_vencimiento /
> editorial / genero / código / titulo
> -----------------

	Alcanzaría con la opción 2 para este problema, ya que no parece
necesario que valga la pena mantener la portada y el resumen de un libro
prestado.
	Sin embargo, para que esto esté bien normalizado, además de editorial y
género habría que guardar sus respectivos ID.
	Lo que te está faltando, no para este ejemplo sino para tu problema
completo, es guardar además id_libro y código interno de la unidad
prestada.

> O sino podría impedir el borrado de libros si tiene unidades que alguna vez
> fueron prestadas y hago:
> (Opción 3)
>  -----------------
>  UNIDADES
> Id / id_libro / código_interno
>  
> PRESTAMOS
> Id / id_unidades / id_asociado / fecha_prestado / fecha_vencimiento /
> id_libro
> ------------------

	Esta opción contradice funcionalidades del sistema, así que sería
inviable. Habría que cambiar el problema para evitar borrado y edición
de ciertos datos de la unidad (si no, corregir un código de unidad o el
nombre de un asociado cambia el pasado de los préstamos) o implementar
una cantidad considerables de artificios para hacer que un dato borrado
no se vea pero siga estando ahí (sin embargo, la "nada" en una DB se
representa no teniendo un registro, y no teniendo un registro con un
dato NULL o inventado estados).

> ¿Son opciones válidas todas, o solo la primera?

	La primera, con el agregado de los ID es la más completa. La segunda
con el agregado de los ID es la mínima que sirve para implementar tu
problema.
	Si tendría que elegir yo, elegiría la mínima necesaria para el problema
en cuestión... tal vez previera alguna cosa mínima futura si supiera
cómo sigue el desarrollo, pero aún así, sería para evaluarlo.

> La misma duda tengo con los visitantes y los comentarios. Si borro un
> visitante el único dato que me interesaría conservar es el nombre que tenía.
> ¿Estoy de todas maneras obligado a duplicar sus otros datos?

	No estás obligado si no implica cambiar o limitar funcionalidades
existentes. Acordate de guardar los ID además de los nombres!

> Repito lo que dije en un correo anterior: evaluar vez tras vez estas cosas
> debe serle tedioso, así que le agradezco mucho la ayuda.

	Depende bastante de la intención del que está del otro lado.
	Si como en este caso, la intención es querer comprender mejor un tema,
no se vuelve tedioso.

	Seguimos!

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key