[Php-avanzado] Tesis Diego Oliva

[Oliva, Diego M.]

Leonardo Tadei - Pegasus Tech Supply wrote:
> Hola Diego,
>
> El jue, 27-11-2008 a las 19:53 -0200, Oliva, Diego M. escribió:
>   
>> Buenas tardes,
>>
>>     Leo, éste sábado no voy a poder ir, asi que voy el miércoles,
>>     
>
> 	Ok.
>
>   
>>  no obstante, para tratar de avanzar un poco, te mando mi "proyecto", asi 
>> como las tablas normalizadas... y un par de dudas...
>>     
>
> 	Genial! Así adelantamos por acá... porque el reloj sigue corriendo...
>
>   
>>     Bue, lo mío era la agenda, empezando, tiene el login y sector 
>> registro de nuevo usuario, el cual debe completar nombre de usuario, 
>> contraseña, y sus datos para la agenda (los que disponga), pero 
>> obligados nombre, apellido, dirección, teléfono y mail. Va a pasar por 
>> una validación, escalable por el administrador del sistema, la cual 
>> tendría, aceptación automática, validacion contra autenticación de mail 
>> por vinculo url (ampliable a soporte de restricción de registro contra 
>> dominios permitidos de mail) o por último, validación por el administrador.
>>     
>
> 	Es decir, el usuario completa los datos pero hasta que el admin no le
> da el Ok, no podrá entrar al sistema.
> 	Es así?
>   
                      Es elegible por el adminsitrador... va a tener 
entre esas opciones... la ultima seria que él es el que decide si un 
usuario que quiere registrarse puede acceder al sistema...

>   
>>        Finalmente, una ves dentro, podrá tanto modificar sus datos (que 
>> serán visibles para cualquier usuario) como agregar contactos nuevos, 
>> los datos posibles a ingresar son: Nombre, Apellido, Direccion o 
>> Direcciones (con descripcion, casa, trabajo, etc...). Teléfono o 
>> teléfonos fijos, los cuales van a estar ligados a las direcciones, 
>> celulares (c/descripción), mails, paginas web (también con descripción)
>>     
>
> 	Suena lindo.
> 	Estás planteando una relación 1-a-N de los contactos con direcciones,
> teléfonos, mails y webs.
> 	A nivel de tablas es una pavada. A nivel de la interfaz con el usuario
> es muy interesante.
>
>   
>> y una foto del contacto. Los teléfonos fijos caen dentro de una 
>> categoria de tipo, y en el caso de no encontrar la categoria requerida, 
>> se envía una notificación al administrador para que, en el caso de 
>> aceptar la categoría, pueda ingresarla al sistema.
>>     
>
> 	Una especia de tagging interactivo... lo de la aceptación del
> administrador suena bien desde el punto de vista del sistema, pero feo
> desde el punto de vista del usuario.
>
>   
>>  El teléfono que quede en espera quedará asignado a una categoría llamada A Designar.
>>     
>
> 	Mmmm... no lo veo usable.
> 	Y que tal un tagging por usuario? Así si un usuario dice que el
> teléfono es de tipo "perejil", esta categoría no estará disponible para
> otros usuarios... Si al crear un usuario tenés unos tags razonables
> predefinidos, en gral no se agregarán muchos más.
>   
                   Asi lo habia pensado originalmente, pero despues me 
arrepenti porq la mayoria de los datos ivan a estar repetidos... es como 
que me asustó la cantidad de registros que tendria esa tabla... pero sí 
me parece lo más practico...

>   
>>        Por otro lado, cada contacto también podrá ser categorizado 
>> dentro de grupos, los cuales estarán regidos por las mismas reglas que 
>> los tipos de los teléfonos. Y también, será posible clasificar un 
>> contacto de "Público", de forma tal que cualquier otro usuario pueda ver 
>> dichos datos.
>>     
>
> 	Si esto lo usás para determinar la visibilidad de un contacto a los
> demás usuarios, las categorías deben ser fijas.
>   

             No, los grupos son independientes de la clasificacion 
"Público", si un contacto es público o no va a estar regido por el 
booleando de la tabla...

             Por otro lado, cada contacto va a estar dentro de un grupo, 
del estilo, Grupo de "Amigos", Grupo del "Trabajo", Grupo de 
"Familiares", etc... y la idea era que dichas categorias también 
estuvieran reguladas por el administrador, pero, de vuelta, si es 
preferible que los grupos sean independientes a cada usuario, mejor.

>   
>>        También podrá consultar la agenda, buscar por nombre o apellido, 
>> listar por letra, en todos o por grupos, modificar los datos de un 
>> contacto, eliminar contactos, etc...
>>
>>     Creo que no me estoy olvidando de nada por ahora... Queda ver si 
>> hice bien la normalización... especialmente porque tengo una duda...
>>     
>
> 	A ver...
>
>   
>>     El sistema esta hecho de forma tal que cada vez que se registre un 
>> usuario, los datos de dicho usuario quedan en la tabla datos, y sin 
>> intervención del usuario van a quedar asignados al grupo, "Usuarios". 
>> Ahora, al querer recuperar los datos de un usuario, por ejemplo, al 
>> loguearse, para encontrar dichos datos tengo que recorrer la tabla 
>> Datos, comparando que el id_usuario corresponda con el usuario y que 
>> además el grupo sea Usuario, puede hacerse, no es dificil, pero algo en 
>> mi cabeza me dice que seria mucho más práctico que este el campo 
>> ID_DATOS en la tabla usuario, como está ahora en negrita... pero según 
>> creo, no esta bien que dicho campo exista... asi que... esa es mi 
>> duda... ¿Cómo hago eso?
>>     
>
> 	No hay que recorrer!!!
> 	Lo importante del SQL es que siempre evita una recorrida, ya que
> restringís la proyección a los datos que te interesan solamente.
> 	En este caso, inventando los nombres de las tablas, sería:
>
> SELECT * FROM Datos WHERE id_usuario=3
>
> en dónde "3" es el id del usuario logueado.
>   

                      Verdad...

>   
>>     Y... ya esta... creo que lo único que me queda por aclarar es que 
>> los nombres de los campos y las tablas son simlemente explicativos y no 
>> van a ser los que use, y que el caso de los tipos de los datos, 
>> posiblemente cambie algunas longitudes en el transcurso del proyecto...
>>
>>     Como todos, cualquier sugerencia es bienvenida...
>>
>>
>> ============================================
>> Tablas ->
>> ============================================
>>
>> Mails_permitidos:
>>
>>        ID (INT)
>>        MAILS
>>     
>
> 	Esto es para la restricción de dominios permitidos para nuevos usuarios
> que mencionás más arriba? Si es así, Mails no es un buen nombre...
>   

                      En efecto, es para eso, y estos no son los nombres 
que voy a dejar... mi intencion es tratar de inventarme alguna regla 
para generar todos nombres cortos y entendibles...
>   
>> Usuarios:
>>
>>        ID (INT)                   
>>        **ID_DATOS (INT)
>>       *USUARIO (VARCHAR 20)
>>        CONTRASEÑA   (VARCHAR 64)
>>        HASH_CREACION (VARCHAR 64)
>>        ACTIVO (BOOLEAN)
>>        ADMINISTRADOR (BOOLEAN)
>>     
>
> 	Qué función cumple el Hash ???
>   

                para la validacion de los usuarios por url... una clave 
md5 o sha aleatoria, que va a estar en la url que se envie por mail para 
dar de alta el usuario, para la validacion...
>   
>> Telefonos:
>>
>>        ID   (INT)
>>        TELEFONO (VARCHAR 15)
>>        INTERNO   (VARCHAR 5)
>>        ID_TIPO   (INT)
>>        ID_DIRECCION    (INT)
>>        ID_DATOS   (INT)
>>        PRINCIPAL   (BOOLEAN)
>>     
>
> 	Arriba decís que los teléfonos se asocian a una dirección, pero cómo se
> comporta esto para el caso de los móviles?
> 	No entiendo cual es el objetivo de esta asociación...
>   
                Los telefonos fijos van a estar asociados a las 
direcciones... los moviles no. pasa que mi razonamiento fue que, un 
telefono fijo, esta fijo, en una direccion, y, por tanto, estaria bueno 
poder relacionar un telefono con su emplazamiento fijo...

                en el caso de los celulares no, solo el celular y su 
descripcion...

> 	
>
>   
>> Tipo_Tel:
>>
>>        ID   (INT)
>>        NOMBRE   (VARCHAR 15)
>>        ACTIVO   (BOOLEAN)
>>     
>
> 	Qué es "activo"? Un borrado lógico? y por qué no físico?
>   

                el activo lo habia puesto como que indicador, por el 
hecho de que un usuario quiere otra categoria de telefono, pero como 
depende de que el administrador la apruebe, que quede en la base de 
datos pero no activa, y si el adminsitrador la aprueba, entonces se 
activa... ahora, si se usan por usuario, entonces no va a tener utilidad 
ese campo...


>   
>> Datos:
>>
>>        ID   (INT)
>>        NOMBRE   (VARCHAR 50)
>>        APELLIDO   (VARCHAR 50)
>>        FOTO   (VARCHAR 50) (Cuando sepa donde las voy a guardar seguro 
>> lo vario...)
>>        PUBLICO   (BOOLEAN)
>>        ID_GRUPO   (INT)
>>        ID_USUARIO   (INT)
>>     
>
> 	Esto significa que cada contacto puede pertenecer a un grupo
> distinto... no está mal, pero no lo aclarás arriba, y en la propuesta
> mia el usuario pertenece a un grupo, y decide si a ese contacto lo ve
> solo él, su grupo, o todos.
>   
                         Si, osea, arriba esta, cada contacto es 
clasificable dentro de un grupo, cada usuario tendria sus grupos, segun 
el actual planteamiento, y, a su ves, cada contacto puede ser.. 
.digamos... etiquetado, como publico, de forma tal que lo van a poder 
ver todos los usuarios...

                      ahora... no entendi esto...  '[...] y decide si a 
ese contacto lo ve solo él, "su grupo", o todos. '
                      no estoy planteando distinos grupos para los 
usuarios....  que me perdi?

> 	Lo que planteás no está mal, pero es otra cosa... y hace falta saber
> esa cosa para ver si la normalización refleja esa situación u otra.
> 	La tabla implica por ejemplo que todos los usuarios tienen que tener
> acceso a ver todos los grupos, para seleccionar el grupo al que
> pertenece el contacto.
>
>   
>> Grupos:
>>
>>        ID   (INT)
>>        NOMBRE   (VARCHAR 30)
>>        ACTIVO   (BOOLEAN)
>>     
>
> 	Idem la pregunta del borrado lógico.
>   

                      lo mismo que para los tipos de telefono...

>   
>> Mails:
>>
>>        ID   (INT)
>>        MAIL   (VARCHAR 50)
>>        ID_DATOS   (INT)
>>        PRINCIPAL   (BOOLEAN)
>>
>> Webs:
>>
>>        ID   (INT)
>>        WEB   (VARCHAR 100)
>>        DESCRIPCION   (VARCHAR 50)
>>        ID_DATOS   (INT)
>>        PRINCIPAL   (BOOLEAN)
>>
>> Moviles:
>>
>>        ID   (INT)
>>        MOVIL   (VARCHAR 15)
>>        DESCRIPCION   (VARCHAR 50)
>>        PRINCIPAL   (BOOLEAN)
>>        ID_DATOS   (INT)
>>     
>
> 	Mmm... tatar os teléfonos fijos y los móviles por separado no sé si es
> buena idea...
> 	Cómo lo justificás?+
>   

                      lo plantee asi por el tema de las direcciones...
>   
>> Direcciones:
>>
>>        ID   (INT)
>>        DIRECCION   (VARCHAR 100)
>>        DESCRIPCION   (VARCHAR 50)
>>        ID_CIUDAD   (INT)
>>        PRINCIPAL   (BOOLEAN)
>>
>> Ciudades:
>>
>>        ID   (INT)
>>        CIUDAD   (VARCHAR 30)
>>        PREFIJO   (VARCHAR 10)
>>        ID_PROVINCIA   (INT)
>>
>> Provincias:
>>
>>        ID   (INT)
>>        PROVINCIA   (VARCHAR 30)
>>        PREFIJO   (VARCHAR 10)
>>        ID_PAIS   (TINYINT)
>>
>> Paises:
>>
>>        ID (TINYINT)
>>        PAIS   (VARCHAR 30)
>>        PREFIJO   (VARCHAR 3)
>>     
>
> 	Para los prefijos de paises usás los ISO, de 2 letras.
> 	No sé si IRAM o alguien tiene un prefijo estándar de Provincias.
> 	Para qué usarías el prefijo de la ciiudad?
>   


                los prefijos no son de las ciudades, provincia, pais en 
si, si no de los telefonos que se encuentren en ellas, mi intencion es 
que se deban escribir los telefonos como si se los fuera a llamar 
localmente, y en el caso de encontrarse en otro pais, saber los 
codigos... por ejemplo, para llamar a mi telefono desde... no se... 
japon... marcar 00 o +, dependiendo de alla, y luego 54, prefijo 
argentina, 11, prefijo buenos aires, 223, prefijo mar del plata, y 
finalmente el telefono... se entiende? no se... me parecio practico... 
aunq si me faltaria codigos postales...
>
> 	Bueno, seguimos en contacto para acotar estas cuestiones.
> 	Saludos!
>   


-- 
Oliva, Diego Martín

www.olivadiegom.com.ar
diego en olivadiegom.com.ar
Tel.: +542235530137
Mar del Plata, Bs. As.
Argentina.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-avanzado/attachments/20081128/7db8f997/attachment-0001.htm