Barrapunto

Políglota [wikipedia.org].

Siempre un problema con las noticias, sino es que son "tres líneas" con abreviaturas (iSCX$, HJSA"%Q), son palabras que no son lo que uno piensa.

Pensaba que un "Políglota" era una persona gorda que comía mucho. :D

La noticia no deja de ser más de lo mismo de siempre. "Usamos tecnología obsoleta"

Los DBM se pueden mejorar. Correcto.

Pero como siempre, depende del caso, y además, está la máxima de "Si funciona, no lo toques".

Por eso, aunque saquen un nuevo DBM que sea mejor, hasta que no lleve años funcionando, ni se me ocurriría pensar en migrar a él, ya que cualquier fallo que tenga, puede dejar mi negocio en "parón", y eso cuesta dinero-

    Que quieres que te diga esto ya esta suciendo hoy en dia, sobretodo en la programación web donde se mezclan php, asp, javascript, ajax, vbscript y lo que haga falta y sea más facil, para poder acabar rápido.

    En realidad lo que uno debe hacer es aprender una metodología y más de un paradigma, y luego con un par de meses no es muy difícil pasar de javascript a vb script,o de python a perl. Pero de c a java o al revés es cierto que la cosa se complica un poco ya que las librerías que usan son completamente distintas y normalmente se programa o se intenta programar toda la aplicación en un solo lenguaje. Pero que ventaja tiene esto? Muy fàcil que no se puede desarollar una aplicación muy grande programando en 8 lenguajes diferentes por el lio de organización que debe suponer. Supongo que si que se puede es basarte en un solo lenguaje y luego si hay que hacer consultas adaptadas a la necessidad de un usuario entonces se puede hacer un pequeño script supongo. Bueno el tema es complicado de cojonessss !!!!

No creo que las bases de datos relacionales tengan ningún problema, funcionan para lo que estan hechas. Otra cosa es que no sirvan para todo.

Para un programa de gestion se usa una base de datos relacional embebida, para una empresa que maneja más datos un servidor de base de datos relacional y los del articulo hablan de un sistema de memoria compartida que funciona en un cluster. Sinceramente, yo veo más probable usar un "obsoleto" sistema de base de datos que el suyo, porque no me hace falta.

Luego también se habla de las limitaciones del modelo relacional. Y claro que las hay. Pero no veo que se hable de las alternativas que existen. Algunos ejemplos:
  * HDF [uiuc.edu] para el manejo de datos jerarquicos. Permite arrays y compresión de los mismos.
  * RRDtools [oetiker.ch] cuando solo nos iteresan los últimos n resultados. Con capacidad de hacer agregaciones de los mismos si hace falta.
  * Mnesia [erlang.org] como ejemplo de base de datos distribuida para aplicaciones de tiempo real.

Y luego dice una cosa muy rara haciendo entender que python, perl y ruby no son lenguajes de proposito general. (PL-)SQL, awk y sed si que me parecen lenguajes de propósito especifico, y también pequeños lenguajes como parece que les gusta llamarlos.

En fin, que no he entendido nada del articulo ese de estos señores. Que alguien me lo explique, por favor.

Hay algo cierto.... las BD relacionales deben incorporar nuevas tendencias tecnológicas desde su núcleo, entre ellas: programación distribuida, etc. Hay muchos problemas que seguramente muchos hemos encontrado a raíz del manejo de grandes bases de datos con millones de registros y que en un simple join pueden resultar un parto manejar. De hecho estoy mirando con mucha expectativa desde hace un buen tiempo lenguajes como erlang y para no apartarme de los micro-threads y la distribución generalizada me auxilio de stackless, el cual está resultando muy útil.

El artículo, según he leido yo por encima (tampoco me lo he papado en profundidad) no dice que el modelo entidad-relación de Chen esté superado, sino que se refiere a la arquitectura de "talla única" (one-size-fits-all) de los grandes sistemas gestores de bases de datos como DB2 u Oracle.

Lo que vienen a decir es que las empresas que crean SGBD's siguen usando una arquitectura desarrollada hace 25 años que no tiene porqué ajustarse bien a todos los casos actuales de uso de bases de datos ni las arquitecturas hardware de hoy en día, pero nadie ataca al modelo teórico en sí mismo. De hecho, las aplicaciones que han montado ellos son E/R.

Esta semana descubrí esta joya:
http://software-lab.de/down.html [software-lab.de]
PicoLisp, un dialecto de Lisp interesante, hecho para ser simple y liviano. Me llamó la atención porque por enésima vez me he decidido a ponerme "esta vez sí" a aprender el lisp, y me tropecé con este, que ganó el año pasado segundo puesto en un test de rendimiento de bases de datos de la revista alemana C't, ganándole incluso a Oracle y DB2: http://common-lisp.net/pipermail/munich-lisp/2006- June/000090.html [common-lisp.net].

Su enfoque en cuanto a bases de datos es autodeclarado como radical, dependiendo severamente de la característica del lisp de que código y datos son iguales (aún estoy tratando de entender eso, el instinto me dice que hay oro ahí, así que sigo persiguiendolo). Además, su interacción con el entorno es o en consola, o por web, con html y applets de java autogenerados. En el sitio hay documentación de su forma de ver las cosas, pero creo que este artículo independiente ayuda a entender esto: "The Nature of Lisp"
http://www.defmacro.org/ramblings/lisp.html [defmacro.org]

Ya me estoy metiendo en el lisp, usando a este entorno como laboratorio, ya veremos...

Seguramente me dirán que estoy fuera de tema, pero es que no puedo evitar preguntar qué tiene que ver la imagen de un carretillo con las bases de datos.

Entiendo que las bases de datos no es de las cosas más sencillas de asociar con un logo o una imagen, pero lo de la carretilla me suena más bien a construcción, lo asocio más con... desarrollo, quizás, pero no con bases de datos.

Pues eso que he sido yo el que puso el mensaje, pero le di a publicar anonimo.

Interesante

¿Podrías decirme de qué manera a groso modo se implementa más eficientemente en el paradigma que mencionas el producto escalar + una selección?

Y lo que cobra el Al Gore por dar una charla lo convierte en uno de los mejores climatologos de mundo, no te jode :-P

Creo que aqui tienes un problema de comprensión, porque el simil que pones es bastante poco acertado. Aqui uno mejor:

Es como decir que las sumas no sirven para multiplicar números de 5 cifras porque es poco practico hacerlo.

E incluso ese simil sería discutible. Porque para determinados problemas, las bases de datos relacionales de toda la vida no te resuelven los problemas en un tiempo aceptable, por lo cual, aunque puedan hacerlo no sirven. Sigue los links de la noticia para ver algunos ejemplos.

Tu comentario parece a la reaccion de esos luditas [wikipedia.org] que atacaban las maquinas porque les cambiaba la forma de vida, en vez de atacar el problema de sus condiciones laborales (el verdadero problema). Debe ser jodido haberse especializado en bases de datos relacionales para que lleguen los de ebay y diga que a ACID le sobran letras o los de FaceBook que gracias al memcache pueden suplir las carencias de las bases de datos relacionales. En fin, renovarse o morir querido DBA.