[Php-avanzado] Tesis Diego Oliva
Oliva, Diego M.
diego en olivadiegom.com.ar
Mar Dic 2 11:54:33 ART 2008
Buenas, contesto por aca porq si no se va a desparramar todo...
El tema de los grupos... a ver... lo que estás planteando es
que cada usuario va a pertenecer a un grupo, y luego, este usuario puede
clasificar a un contacto como privado, como público para su grupo, o
como público para todos los grupos de usuarios, es asi? pero hay algo
que no entiendo... de donde salen los grupos de los usuarios? como hace
un usuario para ser miembro de un grupo? lo elige el? me parece un poco
inseguro... lo designa un administrador? ahora si me parece mucho
trabajo para éste... un usuario puede crear un nuevo grupo?
Lo único que se me ocurre por ahora es que un usuario pueda
crear un grupo, pero que la alta deba ser aprobada por un administrador,
y que, luego, este usuario creador se convierta en un administrador de
su grupo particular, y que él apruebe futuros miembros... pero, de
vuelta, no creo estar entendiendo bien este tema...
Y teléfonos... listo, móviles dentro de tabla teléfonos y que
exista un tipo que sea móviles... no obstante, es verdad, esto no lo
había visto, un celular tiene DDN y DDI, por lo tanto, si bien no
fisicamente, para poder llamarlo está atado a una localidad... pero a
las localidades yo accedia através de la dirección, y dado que no
tienen, como hago? por cada celular creo una dirección con un formato
especifico que indique que es de un celular, o agrego un campo a la
tabla que me indique el id_ciudad? el problema con este último caso es
que ese campo depende de la categoría... es correcto a nivel
normalización hacer eso?
Slds,
Leonardo Tadei - Pegasus Tech Supply wrote:
> Hola Diego!
>
> El vie, 28-11-2008 a las 14:16 -0200, Oliva, Diego M. escribió:
>
>>>> 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...
>>
>
> Ok... mandale una alerta por mail, pobre Administrador...
>
>
>
>>>
>>>
>>>> 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...
>>
>
> No te asustes por la cantidad de datos: los RDBMS están justamente para
> eso... un millón de registros en una tabla no es tanto si tiene el
> índice correcto.
>
>
>>>> 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...
>>
>
> y cómo se entera un usuario de los grupos?
> y cómo sabe qué usuarios estarán dentro de un grupo?
>
>
>> 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.
>>
>
> Pero la idea de los grupos de este trabajo no es solo organizativa,
> sino que es el parámetro para compartir con otros.
> Originalmente, un usuario era miembro de un grupo, y podía compartir
> contactos con su grupo o no.
> Sin este requerimiento el trabajo queda pobre en procesos...
>
>
>>> 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...
>>
>
>
>>>> ============================================
>>>> 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...
>>
>
> Generá nombres descriptivos. Si son cortos, mejor, pero que sean bien
> descriptivos.
> Después si no al leer una consulta no se entiende la intención, porque
> "mails" significa en tu cabeza "correo electrónico" y vos la usás para
> filtrado por nombres de dominio
>
>
>>>> 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...
>>
>
> Ok.
>
>
>>>> 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...
>>
>
> Mmmm... un teléfono es un teléfono... esto no justifica separar ambas
> tablas en dos.
> A lo sumo creá una tabla de teléfonos "pelada" con un código que
> indique el tipo, y si el tipo es "fijo" podés traer direcciones
> asociadas.
>
>
>>>> 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...
>>
>
> Esto de que el sistema no se pueda usar hasta que el administrador lo
> apruebe te aseguro que es una política horrible: cortás la
> escalabilidad, agregás administración innecesaria, convertís en manual
> algo naturalmente automático, hacés que el usuario tenga que esperar...
>
>
>>>> 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...
>>
>
> Te lo discuto más arriba. Si los grupos de la agenda serán para
> clasificar los datos de un usuario, la tesis queda flaca... habría que
> agregarle algo más.
> Si es solo esto tu tesis se resume a un ABM más largo, normalizado y
> nada más. La única query interesante es ver los contactos públicos o
> no... un simple WHERE publico=si en la misma query que trae los datos.
>
>
>> 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?
>>
>
> De la idea de los grupos de personas compartiendo contactos!
> Groupware!!!
>
>
>>>> Grupos:
>>>>
>>>> ID (INT)
>>>> NOMBRE (VARCHAR 30)
>>>> ACTIVO (BOOLEAN)
>>>>
>>>>
>>> Idem la pregunta del borrado lógico.
>>>
>>>
>> lo mismo que para los tipos de telefono...
>>
>
> Arrrggghhhhh!!!! ;-)
>
>
>>>> 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...
>>
>
> Con un discriminante funciona mejor.
> Más arriba está discutido.
>
>
>>>> 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...
>>
>
> Ah! Yo estaba pensando en otra cosa.
> Entonces salta más a la vista lo de los móviles, que también tienen
> código DDN y código DDI pero no están fijados a una dirección.
> Por otra parte, esto no te resuelve cómo hacer una llamada desde fuera
> a un teléfono, porque no tenés el código de ingreso al DDN o DDI de cada
> país.
> Las provincias no tienen prefijos telefónicos.
>
> Esto está para replantearlo, pero no solo la normalización, sino la
> intención del sistema, como contexto de la normalización.
>
> Saludos!
>
> PD: en la parte de login de usuario y sus datos personales ya podés ir
> trabajando...
>
>
--
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/20081202/ad2989c6/attachment-0001.htm
Más información sobre la lista de distribución Php-avanzado