Historias
Slashboxes
Comentarios
 
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • por knocte (3563) el Martes, 13 Septiembre de 2005, 18:32h (#593637)
    ( http://knocte.blogspot.com/ )
    SQL es solo un lenguaje de consulta, tal vez el más usado y estándar, pero uno más.

    INSERT INTO GORLOK(knowledge,facts) VALUES('SQL tambien sirve para modificar datos', 'no solo para consultas')

    El modelo relacional de bases de datos está verificado matemáticamente y cierra por donde lo mires. El problema con las bases de datos orientadas a objetos es que hay muchos acercamientos, pero ningún modelo "completo que cierre".

    Creo que con lo de "cerrar" te entiendo, pero vamos, ya que te estás poniendo tan teórico, podrías ponerte menos "abstracto".

    Por eso el relativo éxito de las bases híbridas "objeto-relacional", que tratan de combinar lo mejor de ambos mundos

    En mi opinión no son lo mejor de los dos mundos, sino lo menos malo para encajar ambos mundos.

    En una base de datos orientada a objetos, los objetos persistentes son objetos de primera clase, y deben ser soportados por el lenguaje.

    ¿De primera clase? ¿Podrías explicarte un poco más?

    El modelo relacional está probado y ha sido implementado con éxito infinidad de veces.

    ¿El paradigma de la orientación a objetos no está implementado con éxito infinidad de veces? ¡Qué sería de Java sin él!

    No creo que muera en el mediano plazo

    En eso estoy de acuerdo.

    Le veo más futuro a los acercamientos híbridos objeto-relacional, y los frameworks de persistencia orientados a objetos (que todavía tienen mucho camino que recorrer).

    Creo que estos frameworks de mapeado objeto-relacional son muy útiles. De hecho, creo que siempre habrían de utilizarse. Pero tienen dos inconvenientes: son muy ineficientes (porque al final donde gastará tu aplicación los ciclos de reloj será en parsear strings, o bien en lanzar consultas y más consultas innecesarias que si hubieras programado tú podrías optimizar mejor porque conoces el modelo de datos), y cuanto más complejos se vuelven (más funcionalidades se añaden a ellos) más hacen que se tenga que seguir lidiando con el modelo relacional en tu aplicación, para mejorar un poquito la eficiencia (p.ej: Lazy loading).

    Por eso creo que estos sistemas no son la solución. Una buena muestra de ello es un gráfico [db4o.com] que hay en la introducción a DB4O, que te da una idea de dónde están estos frameworks y lo que intenta conseguir esta base de datos.
    [ Padre ]