[Php-avanzado] Tesis Diego Oliva

Sab Dic 27 13:17:30 ART 2008

Hola Diego!

	dejo solo las cosas a responder, así el mail no se hace kilométrico:

El vie, 26-12-2008 a las 20:26 -0200, Oliva, Diego M. escribió:        
> > > > 	Ok. Entonces el usuario crea sus grupos para organizar su información?
> > > >   
> > > >       
> > > en efecto, el usuario añade un contacto y lo
> > > categoriza dentro de un grupo, que puede ya existir o puede crearlo en
> > > el momento...
> > >     
> > 
> > 	Es muy confuso el uso que le das a la palabra "grupo"... a veces es
> > para agrupar los contactos, y a veces es para el grupo del usuario.
> > 	Dado que yo leo lo que escribís, y no sé lo que pensás, necesito que lo
> > desambigües.
> > 	
> > 
> >   
> 
>                 hay grupos de usuarios y grupos de contactos
> independientes por cada usuario,

	Que hay dos tipos de grupos me quedó clarísimo.
	La crítica pasaba por como te referís a los grupos, sin hacer
referencia a cual es, lo que hace complicado seguir la estructura.

>  los grupos de usuarios sólo se pueden crear por un administrador y
> van a tener un moderador. Estos grupos poseen miembros, dichos
> miembros son usuarios del sistema, 

	Ok: Grupos de usuarios definidos por el Administrador.
	Punto aparte.

> y cada uno de dichos usuarios puede categorizar sus contactos, sus
> entradas a la agenda, dentro de grupos de contactos, definibles e
> independientes por cada usuario...

	Acá tenés un hueco: si los grupos de contactos los define cada usuario,
no tenés en tus tablas como relacionar a un usuario con sus grupos (o
estoy viendo unas tablas viejas).
	Ahora bien, si relacionás al usuario con sus grupos, cuando se comparte
un contacto, pueden pasar 2 cosas no gratas: que el usuario que ve el
dato compartido no vea de qué grupo es, pero que tampoco lo pueda
categorizar, porque el dato ya tiene su grupo; o que vea los grupos del
usuario que comparte, lo que puede revelar más información de la
necesaria (ej, un contacto en el grupo "cabrones" que se marque como
compartido).

> > > > > > > mails
> > > > > > >   `id` int(11) NOT NULL auto_increment,
> > > > > > >   `mail` varchar(100) NOT NULL,
> > > > > > >   `top` tinyint(1) NOT NULL,
> > > > > > >   `id_data` int(11) NOT NULL,
> > > > > > >     
> > > > > > >         
> > > > > > >             
> > > > > > 	Qué es "top"?
> > > > > > 	Esto es una relación uno a muchos con "data"... 
> > > > > >   
> > > > > >       
> > > > > >           
> > > > > top es un booleano que voy a usar para la muestra
> > > > > de los datos... mi idea es que se vea por cada contacto , rapido, un
> > > > > telefono predetermindo (o preferido), una direccion, un celular, un
> > > > > mail, etc... y despues, si se quiere ver mas información sobre dicho
> > > > > contacto, se ven todos los demas datos que existan...
> > > > >     
> > > > >         
> > > > 	entiendo... y no va a ser único para la tupla id_data + top ??? o puede
> > > > tener varios preferidos?
> > > >   
> > > >       
> > > la idea es que tenga sólo un preferido, dentro
> > > de cada categoria... un mail preferido, un telefono preferido, una
> > > direccion preferida... 
> > >                         por?
> > >     
> > 
> > 	Por que si son únicos por tupla, los podés definir en la tabla como
> > "unique" y tener mas consistencia a nivel de almacenamiento.
> >   
> 
>                    unique no sirve para asegurar que no haya registros
> duplicados?

	Sirve para asegurar que no haya tuplas duplicadas, definidas por la
cantidad de campos que quieras....

> > 
> > 	Esto pide a gritos ver los registros en la tabla "perm".
> > 	Qué va ahí adentro??
> > 
> > 	
> > 
> >   
>                       id y descripcion... por ahora quedaria... 
> 
>                         1 --- Privado
>                         2 --- Para el Grupo de Usuarios
>                         3 --- Publico

	Mucho más claro!
	No se adivinaba por el nombre que esta tabla era la que tenía esto.

> > > > > > > phones
> > > > > > >   `id` int(11) NOT NULL auto_increment,
> > > > > > >   `phone` varchar(20) NOT NULL,
> > > > > > >   `desc` varchar(50) NOT NULL,
> > > > > > >   `id_ptype` int(11) NOT NULL,
> > > > > > >   `id_dir` int(11) NOT NULL,
> > > > > > >   `id_data` int(11) NOT NULL,
> > > > > > >   `top` tinyint(1) NOT NULL,
> > > > > > >     
> > > > > > >         
> > > > > > >             
> > > > > > 	Mmm... asociar una dirección a un teléfono tiene un lado muy flaco: los
> > > > > > móviles.
> > > > > > 	Qué es "top"? 
> > > > > > 	Para qué era esta asociación?
> > > > > >       
> > > > > >           
> > > > 	No me respondés... supongo que es para sacar los prefijos... pero esto
> > > > significa que no se puede anotar un teléfono sin antes cargar la ciudad
> > > > con el prefijo correspondiente. Me sigue pareciendo muy mezclado...
> > > >   
> > > >       
> > > no habia visto ninguna pregunta... lo de top
> > > ya lo habia explicado...
> > > 
> > >                          la asociacion a la que te referis es la de
> > > direccion-telefono? no tiene un fin realmente especifico, simplemente
> > > me parecio practico saber a donde estoy llamando cuando llamo a un
> > > telefono fijo...
> > >     
> > 
> > 	Mmm... me parece una característica que le baja mucho la usabilidad al
> > sistema...
> >   
> >  
> >   
> 
>                 yo queria hacerlo lo mas transparente posible para el
> usuario, si en el momento veia que se me complicaba, iva a perder la
> asociacion, pero no crei tener que llegar a eso...
>                 crees que no vale la pena?
> 

	Yo creo que es una complicación innecesaria. 
	La gente anota los teléfonos con prefijos o internos todo junto. Para
forzar al usuario a que use los prefijos telefónicos asociados a la
dirección, debés restringir la cantidad de caracteres, pero si lo hacés,
no cabe poner un nro de interno o líneas rotativas.
	Si dejás más grande para que entre esto, cuando hacés la composición de
prefijos y nros, se van a ver datos "mal" por estar 2 veces. Además
tendrías que saber dónde está el usuario porque estar en Mardel y ver
"54 223" adelante de todo es "molesto".

> > > > > > > ptypes (Tipos de teléfonos)
> > > > > > >   `id` int(11) NOT NULL auto_increment,
> > > > > > >   `type` varchar(25) NOT NULL,
> > > > > > >     
> > > > > > >         
> > > > > > >             
> > > > > > 	Supongo que para móvil o fijo... pero es realmente importante saber de
> > > > > > qué tipo es?
> > > > > >   
> > > > > >       
> > > > > >           
> > > > > trabajo, oficina, casa, casa de veraneo (:P), mas
> > > > > configurables, y móvil... 
> > > > >     
> > > > >         
> > > > 	Ahhh... pero entonces necesitás la misma descripción para las
> > > > direcciones y posiblemente para los mails...
> > > > 
> > > >   
> > > >       
> > > las direcciones, mails y webs tienen un campo
> > > varchar de descripcion, para dicha aclaracion...
> > >     
> > 
> > 	Sí, pero la misma justificación que usaste para codificarla acá debería
> > ser aplicable a las direcciones y los mails.
> > 	Por qué acá se justifica y en los otros no???
> > 
> >   
> 
>                       porq los telefonos son, en general, bastante
> estables, movil, casa, casa de verano, trabajo, oficina y casi que ya
> esta...

	Supongamos que con esto alcanza... (falta bipper, taller, barco, auto,
fax, modem....)

>  pero en mails y paginas web ya si que hay mucha variacion... mi web
> personal, web de la empresa, mi blog, mi group (google, msn,
> yahoo...), blog del laburo, blog de los amigos, de los hijos, google
> docs y se puede seguir... con los mails no va para tanto, pero casi...

	Pero todos los "blogs" y "grupos", pueden ser también solo personales o
laborales, y no requieren esa discriminación tan fina.
	La parte importante es distinguir una forma de contacto laboral de una
personal, para saber a cuál llamar y cuándo llamar según lo que haga
falta.

	Quiero decir que en el primer caso te arreglás con poco, habiendo
otros, y en los siguientes casos, tu granularidad es muy alta.
	La idea es que las cosas se vean y sientan "parejas".

> > >     
> > 
> > 	Sí, Diego, la relación está abajo.
> > 	Pero mi pregunta sigue sin responder "qué vas a configurar?"
> > 	Necesito entender como pensaste la cosas para validar tu modelo de
> > datos!
> >   
> 
>                    si no es lo que ya respondi, entonces explicame aun
> mas que es lo que me falta porq no me doy cuenta... esto es lo que ya
> mande...
> 
> 
> las configuraciones de las que hablaria rconfig son
> del registro de un nuevo usuario en dicho grupo. de ahi se obtendria
> la informacion de que hacer al ser requerido un nuevo alta de
> usuario... (alta automatico, alta contra comprobación de mail, contra
> comprobacion de mail con mail restringido, contra aprovacion de
> moderador...)

	Entiendo. en otras palabras, estos registros van a estar asociados a
algoritmos que implementen el modo de registro.

	Con tu respuesta, enviame por favor de nuevo las tablas a cómo están
ahora, para charlar sobre el modelo actual de datos.

	Saludos!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key