Re: [Papo-hackers] Charla con Charlie

[John Lenton]

On Mon, Jul 15, 2002 at 08:50:45PM -0300, Carlos Mora wrote:
> 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

porque las tablas las pusimos en mayúsculas, y las columnas en
minúsculas. Al poner las columnas en minúsculas hace falta un
separador explícito (s/hace falta/conviene/), mientras que en
palabras mayuscularizadas no hace falta.

> 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"

Entity es una entidad abstracta, es "toda cosa a la que se le
pueden asociar nombres y/o direcciones y/o (otras cosas)". Es la
cabeza de un árbol de herencias; en el .zot queda bastante claro,
pero resumiendo es

Entity (abstracto)
  AlienEntity (entidades de otros)
    AlienStorehouse (depósitos de otros)
    Contact (contactos en las personas jurídicas)
    Persona (persona jurídica externa)
      Client (cliente)
      Provider (proveedor)
  OwnEntity (entidades propias)
    Employee (empleado)
    OwnStorehouse (depósitos propios)

obviamente hay relaciones entre cualesquiera dos entidades: por
ejemplo, un Contact está relacionado a una persona jurídica, y
eso queda registrado como vos digiste en EntityRelation, pero
además tanto la empresa "Empresa" de tu ejemplo y el contacto
"Contacto" tienen atributos propios, por ejemplo al contacto
quizás le sepas la fecha de cumpleaños y le quieras mandar algún
presente, mientras que a la empresa le vas a saber el límite de
crédito. Estos atributos propios, no comunes a todas las
entidades, son los que van en la tabla de la entidad concreta. Se
entiende?

Ojo que no suponemos que no tengamos que agregar (o sacar?) cosas
del arbol este.

Releyendo tu pregunta, veo que esto lo habías entendido, pero
creo que lo que no habías entendido era que Contact se refiere a
la _persona_fisica_ que es tu contacto en la empresa.

> 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.

La tabla EntityCurrency es "qué monedas maneja la entidad",
depende de la aplicación si esa información es normativa o
informativa. No es en qué moneda se hizo una transacción, pero
por ejemplo si la empresa es paraguaya y acepta pagos en dólares,
gallinas y euros, eso es lo que va en esta tabla.

> 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.

... no están "address_type" y "telephone_type"? Si no, es un bug (creo).

> 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.

no sé, tanto anniversary como UID están en entity pero creo que
hay que elevarlos a la misma categoría que las URLs
(teléfono/dirección)

> 5) El tema Entity, OwnEntity, Persona (no podria haber sido Person?)

Es lo mismo, en realidad. Persona se refiere a Persona Juridica.

> 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. 

hmm, puede ser. Creo que es lo mismo.

> 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.

nope.

-- 
John Lenton (address@hidden) -- Random fortune:
Today, THREE WINOS from DETROIT sold me a framed photo of TAB HUNTER
before his MAKEOVER!