[Php-avanzado] Tesis Diego Oliva
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Mar Dic 23 19:49:18 ART 2008
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?
Y como determinará el sistema (basado en qué dato) la visibilidad de
los contactos???
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?
> 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?
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?
> > > 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...
> > > 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...
> 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?
> > > 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!!!
--
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
Más información sobre la lista de distribución Php-avanzado