[Php-avanzado] [PHP-Avanzado] Tesis Diego Oliva

Vie Nov 28 12:54:37 ART 2008

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í?

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

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

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

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

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

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

> Tipo_Tel:
> 
>        ID   (INT)
>        NOMBRE   (VARCHAR 15)
>        ACTIVO   (BOOLEAN)

	Qué es "activo"? Un borrado lógico? y por qué no físico?

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

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

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

	Bueno, seguimos en contacto para acotar estas cuestiones.
	Saludos!
-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key