No, no he desaparecido 😀
Mientras que Eses ha pasado gran parte del verano en stand-by hasta que mis compañeros de aventura en Madrid terminen de preparar el nuevo curso, he estado avanzando el Proyecto Cavavin cuyo desenlace, espero, debería de tener lugar a lo largo del autoño.
Llegado a este punto, necesito ayuda informativa: este proyecto requiere la creación de una base de datos con mucho contenido. En eso estoy y tengo claro que todo el trabajo realizado a lo largo del verano recompilando MB de información sobre vino – de eso va 😉 – ha de ser puesto a disposición pública; digan lo que digan, compartir es bueno. O, dicho de otra manera, si tu tienes una base y yo tengo una base…
Sólo conozco dos maneras de poner a disposición pública una base de datos: colgándola en la red para su descarga libre o colgándola en un servidor y dejando que cualquiera tire de ella a través de consultas.
No me convence ninguna de las 2. La primera por motivos prácticos: obliga a la gente a descargarla entera cada vez que se efectua un cambio, aunque sea un cambio mínimo tipo corrección ortográfica. Y la segunda porque, aunque tiene la ventaja de que las actualizaciones se apliquen en seguida, el ancho de banda que supone es excesivo y sobre todo absurdo pues equivale a hacerle a la base fuente la misma pregunta cada dos por tres.
Busco:
Lo que me planteo es algo parecido a la sindicación RSS o al aviso de actualización de software:
- La primera vez, uno descarga la base fuente entera.
- Tira a la «papelera» lo que no le gusta (datos, formularios,…)
- Añade lo que le apetece (datos, consultas, informes,…)
- Recibe avisos de actualización de la base fuente
- Echa un ojo a la descripción del contenido de la actualización
- Decide ejecutar la actualización
- Se actualizan los datos concernidos y relacionados de su base
Otra alternativa consiste en una vinculación de tablas a través de Internet, con el inconveniente de que sólo se transmite el contenido sin continente, pero algo es algo.
En los dos casos, la sindicación/vinculación requerería inscripción gratuita previa, entre otras cosas para comprobar que los trabajos resultantes también están puestos a disposición pública (*) en lo que sería una especie de «share alike» aplicado a la información.
(*) en la medida en la que se cumple la legalidad pues cada base de datos tiene logicamente una parte privada como pueden ser ficheros de clientes y currantes,…
Otras aplicaciones:
- Otro ejemplo de aplicación – la utilidad pública de una base de datos sobre vino no resulta quizás del todo evidente pues para muchos se trata más de beberlo que de leerlo 😉 – es la información geopolítica del planeta, país, provincia,.. con los nombres de paises, provincias, ayuntamientos,… las banderas, las monedas, los códigos ISO, los dominios, la cartografia,….
Entiendo que cada organismo/administración públic@ responsable de dichas nomenclaturas debería de tener a disposición de los ciudadanos no solamente las bases de datos con esta informácion para ser procesada sino un servicio como el descrito anteriormente. Fomentaría, entre otras cosas, el uso masivo de teminología y datos estandares.
- En cuanto a una aplicación profesional/comercial, pienso por ejemplos en los fabricantes (digamos tecnológicos,…) que han de informar de las caracteristicas técnicas de sus productos (digamos ordenador,…) a su red de distribución (digamos grandes y puequeños tiendas físicas o en red,…) los cuales han de adecuarla a su programa de gestión para restituirl dicha información a los clientes. Si hubiera una sindicación/vinculación entre la base de distribuidor y la del fabricante, además de evitar emillones de e-mails con la recompilación de las carácteristas de un nuevo producto, se evitaría muchos errores al pasar la información en caso de las pequeñas empresas y cualquier cambio de un fabricante estaría reflejado en la web del propio distribuidor al momento.
-
La verdad es que lo estoy contando como si fuera algo nuevo porque lo es para mí, pero no hay duda de que en alguna parte de la red ya existe algo al respecto. Google no me lo ha querido decir, por eso cualquier información en este sentido (tengo pruebas de que hay infórmaticos leyendo este blog 😛 ) sería bienvenida.
Gracias
Media ración de albóndigas cerebrales 
Hola 1ppy,
Realmente el ancho de banda no es algo que suponga mucho coste. Cada día aparecen nuevos servicios que abaratan este tipo de costes y está claro que serán aún más baratos por la competencia existente. Probablemente con el presupuesto para crear un sistema como el que dices podrías pagar ancho de banda para varios años. 😉
Además, supongamos que tienes una base de datos enorme, con cientos de miles de datos. ¿los usuarios necesitarán toda esa información? o solo un pequeño porcentaje como suele ocurrir. Si la primera vez les haces descargarse toda la base de datos, probablemente el usuario esté usando más ancho de banda de la que probablemente vaya a usar nunca.
Yo creo que hoy en día hay que tender hacia lo contrario. El usuario tiene una caja tonta que solo hace consultas y todo está centralizado en servidores. Mucho más manejable y más sencillo cuando se requiera una actualización. 🙂
¿No vale con Web Services?
Gnomo,
Gracias. Lo que he leído sobre Web Services a raíz de tu respuesta me ha dejado igual que como estaba: las explicaciones que encontré (wikipedia y otros) son muy técnicas para un no-profesional (buscando artículo «Web Services para Dummies»…) 😉
Limay,
En primer lugar, si bien es verdad que el ancho de banda cuesta cada vez menos, eso es más aplicable a la bajada de datos que a la subida. Y el problema al que me refiero es de subida. Algo parecido al «robo de ancho de banda» cuando enlazas a imagenes de web ajenas en lugar de alojarlas en tu servidor.
En segundo lugar, no creo que haga falta ni siquiera presupuesto para crear (caso de no existir) el sistema que describo. ¿Cuánto cuesta el RSS de un blog? nada.
En tercer lugar, me interesa más el asunto desde un punto de vista cualitativo que cantitativo. Siempre resultará mucho más práctico tener los datos – filtrados según necesidad – que necesitas en tu servidor: podrás manejarlos como quieras por ejemplo añadiendo campos – y datos – , algo imposible si tiras de consultas SQL sobre la base entera salvo con una consulta de creación de tabla en cuyo caso acabas almecenando los datos de la base en tu servidor… Q.E.D
Por no hablar de la ventaja que resulta tener los datos de las tablas delante de los ojos.
Por último, podemos ver el asunto desde un punto de vista semántico: yo tengo información, te doy toda la que quieras y si cambio algo te aviso. Me parece mucho mejor que: yo tengo información y cada vez que quieres algo me la preguntas.
No creo que quieras que cualquiera tire de tu BBDD que dejas libre en Internet… Lo mejor es crear un Web Service con tu info. Es un mecanismo con el que cualquier usuario puede acceder a la información que tú quieras ofrecer, ni más ni menos. La API de youtube, de twitter… Puedes acceder a la información que hay en sus BBDD programáticamente.
Lo que dices de sindicar el contenido, hombre puedes crear un RSS con una lista de vinos y a cada cambio de la BBDD actualizar el RSS. Pero con una información más compleja sería más complicado.
Saludos,
Omar
Hay una cosa que no entiendo. Cuando explicas el RSS dices que llega un aviso de la «BD Central», se mira la descripción y se ejecuta la actualización. ¿Habría algun caso en el cual el dueño de la BD Local no querría ejecutar esa actualización?
A lo que me refiero es a que si ese cuerpo de información común a todas las BBDD Locales (que es lo que se actualiza a través de la sindicación) siempre deberá ser consistente e igual al de la BD Central.
Concretando un poco más lo de la sindicación. Se podría tener un servicio en cada una de las BD locales que recibiese de la central una notificación y un script maestro SQL de actualización de la BD de la versión x a la x+1. Esto obligaría a que si alguien tiene la versión 131 y quiere poner la 133, pero no quiso poner en su día la 132, debería ejecutar 131to132.sql y 132to133.sql. Es decir, no habría manera de ignorar unos cambios e implantar otros; porque ese tronco de la BD sería común.
Yo también abogo por tener una BD central a modo de data center, o bien hacer un tinglado de base de datos federada. Pero si te empeñas en tener los datos delante, se puede mirar… 🙂
Tienes razón Alberto, es absurdo que una BD local no quiera ejecutar una actualización de datos.
1º – Siempre existiría la posibilidad de establecer filtros previos sobre las actualizaciones (en una BD sobre países y capitales del mundo, limitarse a Europa por ejemplo.)
2º – Y además, como mencionas, daría problemas para actualizaciones siguientes.
Te emilio.
Pingback: Sindicación de bases de datos (II) « 1ppy 2.0 –> Un Proyecto Para You Too (dot zero)