[Php-avanzado] Estructura de base de datos de SALI+
Silverzero
silverzero.52 en gmail.com
Lun Ago 31 15:00:24 ART 2009
2009/8/31 Leonardo Tadei - Pegasus Tech Supply <leonardot en pegasusnet.com.ar>
> Hola Carolina,
>
> El dom, 30-08-2009 a las 20:37 -0300, Silverzero escribió:
> > Hola Leo,
> >
> > En las tablas eventos_status, actividades_status y lugares_status, los
> > 3 estados posibles son activo, inactivo, destacado...Creo que es mejor
> > que estén ahi juntos en vez de hacer una tabla con destacado: Si-No.
>
> Es correcto como lo pensaste... pero si los 3 estados posibles son
> los
> mismos, lo que tenés que hacer es tener una sola tabla "status" y usarla
> para los tres... la repetición no se justifica.
>
----------------------------------> Pero como los referencio? Porque no
tengo un id_publicacion...
Sería id, stat, id_evento, id_actividad, id_lugar?
>
> > Ya que está agregué las tablas Provincias y Localidades, así ya
> > quedan.
>
> Ok.
>
> > Tengo una duda que se me presentó a último momento, a ver si me podés
> > aconsejar qué sería lo más conveniente. Todas los "eventos" y
> > "actividades" suceden en "lugares", por lo que cuando un visitante
> > publica, a la hora de decir en dónde es puede elegir de un menú
> > desplegable entre los que ya fueron previamente cargados, o puede
> > agregarlo si es que no existe.
>
> La gente tiene a agregar sin fijarse si existe o no... creo que lo
> que
> te conviene es que se agregue siempre, pero antes del INSERT lo buscás
> por algún criterio y si existe lo referenciás o editás si vale la pena
> para usarlo (1).
>
> > Ahora el tema es que, tal vez ese visitante no le interese completar
> > TODOS los datos, porque no tiene ganas o porque no tiene toda la
> > información correspondiente, por lo que ese "lugar" va a quedar
> > guardado con su cuenta. Entonces, si al día siguiente el dueño del
> > lugar, o alguien que sí tiene información más completa del mismo
> > quiere publicar, no va a poder porque el sistema le va a decir que ya
> > existe, y si evito eso va a haber lugares repetidos, por más que
> > alguno tenga más o menos datos...
>
> Se entiende...
>
> > Así mismo, noté que este problema se puede presentar con los eventos y
> > actividades, ya que si la información es subida por una persona que
> > sólo publica por el hecho que le gusta el evento, pero no forma parte
> > de la organización del mismo, después no va a ser editable por el real
> > responsable que quiera promocionarlo de mejor manera, y ahi van a
> > querer intervención del administrador para poder modificarlo, y va a
> > ser molesto.
>
> Es cierto... sin embargo podés dejar la edición pendiente para ser
> aprobada por el que la cargó primero, o usar alguna estrategia semejante
> (2).
>
> > Con lo cual se me ocurrió una opción comunitaria (con sub-opción
> > capitalista): Que cualquier publicación pueda ser editada por
> > cualquier visitante, a lo wikipedia style. Y si el propietario del
> > lugar, o el real organizador de un evento o actividad no quiere que
> > nadie lo edite más, que se ponga con un destacado.
> >
> > ¿Qué opinás?
>
> También es una buena opción, que hasta se puede conjugar con la
> (1).
>
> Ahora bien, con estas cosas tu proyecto, que ya es grande, se
> agranda
> más todavía, y no me gusta, porque te va a llevar demasiado tiempo
> escribirlo con todo lo que esto implica...
>
-------------> De todas formas no voy a llegar a entregar para el sábado,
pero no voy a abandonar. Tardaré un poco más, pero lo haré! Tengo este
proyecto desde hace un montón trabado, es una meta importante para mí
terminarlo.
>
> > A continuación te transcribo la estructura de la DB.
>
> Pero todo lo anterior me dejó una duda: si los Lugares se manejan
> así,
> tendrás que hacer que los eventos y las actividades apunten al id_lugar,
> lo cual no pasa en una de las tablas... por qué?
>
> Te intercalo comentarios:
>
>
> > -- Estructura de tabla para la tabla `actividades`
> > --
> >
> > CREATE TABLE IF NOT EXISTS `actividades` (
> > `id` int(11) NOT NULL auto_increment,
> > `fecha` date NOT NULL,
> > `titulo` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `direccion` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `telefono` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `horario` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `descripcion` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `imagen` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `url` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `id_visitante` int(11) NOT NULL,
> > PRIMARY KEY (`id`)
> > ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
> > AUTO_INCREMENT=1 ;
>
> Acá por ejemplo, tenés dirección, teléfono y más datos, cuando
> pareciera que debe ir un id_lugar... podés justificar por qué no va solo
> el id_lugar ???
>
>
-------------> Porque me confundí! creo que usé de referencia una version
vieja que tenia en un txt. Se me chispoteó!
>
> > --
> > -- Estructura de tabla para la tabla `lugares`
> > --
> >
> > CREATE TABLE IF NOT EXISTS `lugares` (
> > `id` int(11) NOT NULL auto_increment,
> > `fecha` date NOT NULL,
> > `nombre` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `direccion` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `telefono` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `horario` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `descripcion` text collate utf8_unicode_ci NOT NULL,
> > `imagen` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `url` varchar(50) collate utf8_unicode_ci NOT NULL,
> > `id_visitante` int(11) NOT NULL,
> > `cod_loc` int(4) NOT NULL,
> > PRIMARY KEY (`id`)
> > ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
> > AUTO_INCREMENT=1 ;
>
> Es relevante que el Lugar tenga fecha y horario??? Bueno, horario
> de
> funcionamiento tal vez, pero fecha?
>
> ------------------------> si, sería el horario de atención si se quiere
poner, y la fecha es la fecha de publicación, para saber cuando fué
ingresado. Y me dí cuenta que en actividades no lo puse, hay una sola fecha,
tendria que haber fecha y fecha_act, o desde-hasta, por si la actividad dura
varios dias.
Gracias por todo!
Saludos.
------------ 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/20090831/6ed0b7b4/attachment.htm
Más información sobre la lista de distribución Php-avanzado