[Php-avanzado] Tesis Diego Oliva
Oliva, Diego M.
diego en olivadiegom.com.ar
Mar Dic 23 21:43:49 ART 2008
Leonardo Tadei - Pegasus Tech Supply wrote:
> Hola Diego,
>
> o tenés algo para la mona, o entiendo que estás modelando... :(
>
> A ver, a ver...
>
> El mar, 23-12-2008 a las 14:32 -0200, Oliva, Diego M. escribió:
>
>>>> --------
>>>>
>>>> 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...
>>
>
> 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...
> Y como determinará el sistema (basado en qué dato) la visibilidad de
> los contactos???
>
no se a que te referis con esto... el listado de
los contactos por usuario? los contactos a los que tiene permiso el
usuario para acceder?
> Hay más abajo una columna "perm", pero está asociada a un dato, y no a
> un grupo...
>
>
>>>> 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...
>>
>
> Ahh... es un modelado "raro"... no todas las ciudades tienen un único
> prefijo de acceso, y 2 ciudades pueden tener el mismo prefijo (Ej.
> Santiago del Estero y La Banda)
>
>
>>>> 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.
>>
>
> Entonces esa columna se llama id_cgroup... usá tu propia convención de
> nombres!!!!
>
>
>>>> 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?
>
>> y lo de la relación... estoy mareado... cada
>> contacto puede tener muchos mails asignados... los que se quiera... no
>> se debe hacer asi?
>>
>
> Yo entiendo que para tu sistema debe ser así... por eso lo afirmaba en
> el mail.
>
>
>>>> 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...
>>
>
> Ok... y el perm y en id no son para la misma cosa entonces?
>
si... es lo mismo que me paso con los tipos de
usuarios...
> Por otra parte, no me doy cuenta cómo esto refleja el tema de que la
> visibilidad tendrá solo 3 aspectos: privado, del grupo y público.
> Privado y público están claros. Del Grupo, significa el grupo del
> usuario, y el usuario tiene grupo, pero no "permisos". Para qué sirve
> esta tabla entonces?
>
el usuario no tiene permisos, cada contacto es el que
tiene permisos, y en base a esos permisos un usuario podra o no ver un
determinado contacto... el usuario podrá ver sus contactos, a su vez
podrá ver los contactos que tengan permiso público y, también, podrá ver
los contactos que usuarios de su mismo grupo haya hecho publicos para
dicho grupo...
>
>>>> 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...
>
>>>> 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...
>>
>
> Ok.
>
>
>>>> 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...
>>
>
> Ok.
>
>
>>>> 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...
>> 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?
>>>
>
>
> Y? Qué vas a configurar con esos datos?
>
esta abajo...
>
>>>> 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...)
>>
>
> Ok... lo voy a querer ver implementado ;-)
>
>
>>>> 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...
>>
>
> Ok.
>
>
>>>> 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,
>>
>
>
> Ok.
>
> Seguimos!!!
>
>
--
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/11f8386d/attachment-0001.htm
Más información sobre la lista de distribución Php-avanzado