[Php-avanzado] Tesis Diego Oliva
Oliva, Diego M.
diego en olivadiegom.com.ar
Mar Dic 23 14:32:45 ART 2008
Leonardo Tadei - Pegasus Tech Supply wrote:
> Hola Diego,
>
> El lun, 22-12-2008 a las 12:35 -0200, Oliva, Diego M. escribió:
>
>> Leo, acabo de volver a mardel, y no me llego ninguna respuesta, asi
>> que te lo mando por de vuelta por si se perdio algun mail por el
>> camino...
>>
>
> Había recibido este mail.
> La verdad es que no me acuerdo si te había respondido o no...
>
> Se me hace bastante difícil seguir las tablas para controlar la
> normalización: esa mezcla de nombres en inglés con castellano y nombres
> genéricos... (cities y provs... una tabla "data")
>
> A falta de semántica para entender el almacenamiento, es bueno por
> ejemplo poner uno o 2 datos representativos para ver los enganches de
> una cosa con otra.
>
>
>> Voy a ver si llego para el 27...
>>
>
> Más que observaciones, te consulto cosas que no entiendo:
>
>
>> --------
>>
>> Buenas, Leo, te mando todo el proyecto de vuelta, a ver ahora que
>> tul...
>>
>> Agenda...
>>
>> Registro de nuevo usuario:
>>
>> Datos: Nombre de usuario, Contraseña, Nombre,
>> Apellido, Dirección, Teléfono, Mail (Obligados), y optativos, los
>> mismos que van a tener los contactos.
>> El usuario va a poder elegir de una lista un
>> grupo al cual inscribirse o va a tener la opción de crear un nuevo
>> grupo. En el primero de los casos, el alta va a estar regido por una
>> configuración independiente para cada grupo, que tiene de opciones:
>> registro automático; registro contra verificación de mail, registro
>> contra verificación de mail con direcciones de mail excluyentes,
>> registro contra aprobación del moderador del grupo. Si el usuario se
>> está registrando y a su vez quiere dar de alta un nuevo grupo, va todo
>> contra aprobación de administrador.
>>
>> Una vez dentro del sistema:
>>
>> Cada usuario va a poder dar de alta nuevos
>> contactos, asi como eliminar y modificar antiguos.
>> Cada contacto va a contar con los campos de
>> información: Nombre, Apellido, Una Foto, Múltiples Direcciones,
>> Múltiples Teléfonos, Múltiples Móviles, Múltiples E-Mails, Múltiples
>> Páginas Web. También es posible categorizar cada contacto dentro de un
>> grupo, y dichos grupos son únicos para cada usuario. Los teléfonos se
>> pueden clasificar como de un tipo (Móvil, Hogar, Trabajo, Etc), a los
>> cuales pueden ser agregados otros, también, únicos para cada usuario.
>> Por otro lado, también se deberá definir uno de todos los múltiples de
>> cada cosa como principal, para una mejor gestión de la información. Y,
>> por último, es posible definir permisos para cada contacto, para que
>> el mencionado pueda ser visible por el grupo al que pertenece el
>> usuario, para cualquier usuario del sistema, o que quede como privado.
>>
>> Luego, la consulta: cada usuario va a tener
>> acceso a sus propios contactos, va a poder realizar busquedas por
>> nombre o apellido, listar por inicial de nombre o apellido y retringir
>> busquedas y listados a los distintos grupos. Y también podrá
>> visualizar aquellos contactos que tengan permisos suficientes como
>> para que el usuario logeado pueda ver.
>>
>> Cada usuario va a tener su propia información
>> personal, la cual será visible para su grupo o para todos los
>> usuarios, configurable por dicho usuario.
>>
>>
>> -------------- TABLAS -------------
>>
>> cgroups (Grupos de los Contactos)
>> `id` int(11) NOT NULL auto_increment,
>> `group` varchar(50) NOT NULL,
>>
>
> y con qué se relacionan estos grupos de contactos? Con el usuario? con
> el grupo?
>
con los contactos... son los grupos que va tener
cada usuario, dentro de los cuales va a poder clasificar a sus contactos...
>
>> cities
>> `id` int(11) NOT NULL auto_increment,
>> `city` varchar(100) NOT NULL,
>> `pre` varchar(10) NOT NULL,
>> `zip` varchar(10) NOT NULL,
>> `id_prov` int(11) NOT NULL,
>>
>
> Qué es "pre"?
>
El prefijo telefónico...
>
>> country
>> `id` int(11) NOT NULL,
>> `country` varchar(100) NOT NULL,
>> `pre` varchar(4) NOT NULL,
>>
>
> Qué es "pre"?
>
>
>> data
>> `id` int(11) NOT NULL auto_increment,
>> `name` varchar(100) NOT NULL,
>> `lname` varchar(100) NOT NULL,
>> `pic` varchar(100) NOT NULL,
>> `id_group` int(11) NOT NULL,
>> `id_user` int(11) NOT NULL,
>> `id_perm` int(11) NOT NULL,
>>
>
> Data de qué? de los usuarios registrados? de las entradas de la agenda?
> No está bien tener el id_user y el id_group: con el id_user encontrás
> el grupo correspondiente....
>
>
Data de todo el mundo... cada usuario registrado
va a tener que completar sus datos, los cuales van a ser los mismos que
los de la agenda propiamente dicha, por lo tanto todos los datos, ya sea
de un usuario o de un contacto, van a ir a la misma tabla...
el id_group que aparece aca no es el del grupo al
que pertenece el usuario, sino al del grupo que pertenece el contacto.
>> 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...
y lo de la relación... estoy mareado... cada contacto
puede tener muchos mails asignados... los que se quiera... no se debe
hacer asi?
>
>> perm (Permisos disponibles para los contactos)
>> `id` int(11) NOT NULL auto_increment,
>> `perm` tinyint(4) NOT NULL,
>> `desc` varchar(50) NOT NULL,
>>
>
> O sea, permiso disponible para que un usuario asigne a sus contactos???
>
si... para lo de privado, publico para el grupo al
que pertenece el usuario, y publico para todo usuario...
>
>> 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?
>
>
>> pmails (Mails que serán permitidos al registro)
>> `id` int(11) NOT NULL,
>> `pmails` varchar(100) NOT NULL,
>>
>
> Para todos?!?!?!?
> No tiene más sentido tener mails permitidos por grupo?
> Quién administra qué mails se permiten y a dónde?
>
verdad...
pmails (mails que serán permitidos al registro)
`id` int(11) NOT NULL,
`pmails` varchar(100) NOT NULL,
`id_ugroups` int(11) NOT NULL,
moderador y administrador... panel de control...
>
>> prov
>> `id` int(11) NOT NULL,
>> `prov` varchar(100) NOT NULL,
>> `id_pais` int(11) NOT NULL,
>>
>
> id_pais? Pero si la tabla se llamaba "country".
> Para seguir en inglés, esta tabla debería llamarse "county" o
> "states"...
> Decidite con el idioma porque si no, no es simple de entender... a mi
> me da lo mismo cualquiera, pero sé homogéneo!
>
verdad :) se me chispoteo... sería id_country...
>
>> 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...
para mi modelo de almacenamiento es importante...
>
>> rconfig (Configuración del registro)
>> `id` tinyint(4) NOT NULL,
>> `desc` varchar(50) NOT NULL,
>>
>
> Del registro del usuario? De un registro de una tabla de la DB?
> Por ser una configuración, tener solo descripción como valor no es
> poco? Qué vas a configurar?
>
>
>> ugroups (Grupos de usuarios)
>> `id` int(11) NOT NULL auto_increment,
>> `group` varchar(50) NOT NULL,
>> `id_rconfig` tinyint(4) NOT NULL,
>> `desc` varchar(250) NOT NULL,
>>
>
> Aja! El grupo tiene una configuración... pero cómo tu sistema resolverá
> que hacer según esa configuración? En qué consiste configurar un grupo?
>
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...)
>
>> users
>> `id` int(11) NOT NULL auto_increment,
>> `user` varchar(30) NOT NULL,
>> `pass` varchar(64) NOT NULL,
>> `chash` varchar(64) NOT NULL,
>> `id_type` tinyint(4) NOT NULL,
>> `id_group` int(11) NOT NULL,
>>
>
>
> Los usuarios no tienen nombre y apellido ?!?!?!?
>
no dentro de esta tabla... cada usuario va a tener
asociado un registro en la tabla data, de forma de poder tener la
flexibilidad de datos que tienen los contactos...
>
>> utypes (Tipos de usuarios)
>> `id` int(11) NOT NULL auto_increment,
>> `type` tinyint(4) NOT NULL,
>> `desc` varchar(250) NOT NULL,
>>
>
> Para qué hay un id y un type? No son lo mismo?
>
eh.... la verdad que si...
>
>> webs
>> `id` int(11) NOT NULL auto_increment,
>> `web` varchar(150) NOT NULL,
>> `desc` 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 las entradas en la agenda. Bien.
> Y Cómo se guarda una dirección física? Para qué están las ciudades y
> los paises???
>
la relacion por la misma razon que los mails...
y me comi la tabla dirs...
dirs
`id` INT NOT NULL AUTO_INCREMENT ,
`dir` VARCHAR( 150 ) NOT NULL ,
`desc` VARCHAR( 200 ) NOT NULL ,
`id_city` INT NOT NULL ,
`id_data` INT NOT NULL ,
`top` TINYINT(1) NOT NULL,
>
>
>> Saludos,
>>
>
> =mente!
>
--
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/20081223/04825d25/attachment-0001.htm
Más información sobre la lista de distribución Php-avanzado