[Papo-hackers] Charla con Charlie

[Carlos Mora]

Hola a todos,
        He empezado a revisar el ER del PAPO, y me han empezado a surgir 
algunas dudas. 
Inicialmente la conversación fue bien tolerada por Charlie Navarro, pero como 
se quería ir a 
su casa a dedicarse a la bebida, me sugirió que posteara la conversación acá, a 
ver si arrimo 
el bochín un poco. Está recortado porque el diálogo es demasiado largo, pero en 
resumen

Observaciones en el ER:

Nótese que estoy aún en el proceso de captar el concepto global del
diseño, y algunas cosas son más dificiles de percibir que otras solo
leyendo el ER, así es que si alguna cosa resulta obvia o estúpida,
>/dev/nul

0)
Porque en los nombres de las tablas se usan Caps para separar palabras y
en los nombre de columna el undescore?

ej. PersonaTaxProfile vs. price_type

1)

Contact no es redundante? Todavía no terminé de entender la idea de             
                    
Entity, pero Contact no sería un caso especial de relación entre dos            
             
entidades? O sea          

En Entity
   1 row para empresa
   1 row para el contacto
                                   
Y en EntityRelation
   EntityFrom: Empresa
   EntityTo: Contacto
   relation: (RelationType) "Contacto"

2)
EntityCurrency?
CreditLimit?
Creo que esta definición no está en este nivel en la jerarquía de
clases, sino en una clase más especializada, digamos Cliente o Proveedor.

Para Currency en particular, el scope está dado más por la transacción
en particular, y no asociado a la Entidad como un dato global y
permanente.

3)
Address y Telephone
Agregarle una columna más, digamos "tipo" o "clase" para distinguir
entre el fax, los fijos, el de la central telefonica, particular, laboral, etc.
y domicilio de facturacion, envio, alternativo, fiscal, real, etc.

4)
Entity ->Anniversary Should be BornDate
Aniversario es el evento de que se repite anualmente de existencia (anni
versum creo que era la raiz, repetición anual sería), es decir que no
hay uno solo, sino uno para cada año a partir de la fecha de
Naciemiento/creación/existencia, segun sea una Persona Física o
Jurídica, máquina, sucursal, etc.
                                    
5) El tema Entity, OwnEntity, Persona (no podria haber sido Person?) está medio 
complejo, si 
bien va hacia un modelado de una realidad bastante absoluta, los conceptos de 
cada clase me 
quedaron mezclados. 
Al parecer la jerarquia viene por especializacion, por extensión, y creo que 
queda mejor como 
composición entre dos clases: Persona (ser humano con datos filiatorios y 
cuestiones 
relevantes) y Organización como actor de las transacciones del programa. Así no 
se confunde 
el hecho de que en esta segunda clase hay Personas Físicas. 


Bue.. me están echando, sigo mañana...

Hay algo de documentacion ademas de los diagramas? Algun pseudo relevamiento, 
checklist de 
requerimientos, limites y alcances, funciones, etc.

Saludos