[Php-avanzado] DER

[Leonardo Tadei - Pegasus Tech Supply]

Hola Jorge,

	La cosa mejora!

El lun, 26-11-2012 a las 19:43 -0300, Jorge Di Iorio escribió:
> Leo,
> 
> 
>       Buenas Tardes, ahí te mando nuevamente le DER con las
> observaciones que me hiciste corregidas. Si te parece bien, arranco a
> hacer los ABMC.

	Más allá de mi parecer, tu DER no está en 3FN (Boyd-Cood).

	Antes de empezar, tengo una duda: cuando en el gráfico planteás que un
campo es una FK, implica esto algo a nivel del maneje de datos?
	En otras palabras, si Canchas tiene como FK id_complejo, al borrar un
Complejo, qué pasa con las Cachas que tiene relacionadas en la DB?
	A esto hay dos respuestas con algunos matices: lo que pasa lo maneja el
software; y lo que pasa lo maneja la DB.

	Cuál será el caso?

	Volviendo a la DER:

a) En Estados seguís teniendo un campo discriminador. En la SRS tenés 3
tipos de Estados para 3 Entidades distintas. Es posible que en este
nivel los Estados de Reservas y los Estados de Reservas Fijas puedan ser
los mismos, ya que tendría sentido que tengan los mismos valores, pero
los Estados de los Alquileres ni se le parecen.
	Fijate si los Estados para ambos tipos de reserva pueden ser los
mismos, con lo que las Reservas tendrían los mismos estados posibles. Si
tiene sentido, te quedarán dos tablas, si no tiene sentido te quedarán 3
tablas.

b) En Alquileres te decía la iteración pasada que "recargo" y
"descuento" son el mismo dato. Si nunca que se hace un recargo se puede
hacer un descuento, y viceversa, uno de los dos campos sobra.

c) También en Alquileres, al igual que con el Cliente y la Tarifa, tenés
que poner los datos de la Cancha y del Complejo, ya que si no el borrar
una Cancha o un Complejo, perdés la referencia de los Alquileres que las
usaban.
	Con el Cliente, ya que en el problema estos tienen un código, parece
buena idea que este dato también estén en Alquileres, además del
apellido y nombre.
	Para las Reservas parece no hacer falta, porque la Reserva, en tanto
que una promesa de futuro, vale la pena solo si los datos relacionados
son actuales.


>       Con lo de los campos discriminadores me hiciste acordar a un
> compañero de laburo al cual un vez le pregunte porque había "cableado"
> un dato (estaba haciendo un if contra un valor que supuestamente nunca
> iba a cambiar, pero igualmente lo correcto era tomarlo de
> un parámetro). Su respuesta fue la siguiente: "Perdón! ésto no está
> cableado, está finamente ligado..."

	Ahhh.... hacer las cosas mal parece tan fácil, y tiene tanto costo
oculto!

http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica
http://www.microlopez.org/2011/02/11/deuda-tecnica-la-burbuja-de-las-tic/

>       Saludos

	=mente!

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