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 pobrecito hablador el Sábado, 26 Abril de 2003, 21:41h (#178705)
    Muchos profesionales de Tecnologías de la Información de los que como yo nos hemos pegado con MySQL hasta cansarnos, esperamos que o bien cosas que se esperan que funcionen como es la réplica entre bases de datos ya funcionen bien, o que nuestro presupuesto permita comprar una licencia de Oracle... Si has tenido MySQL en un entorno de producción 24x7 sabrás lo que es depender de esa "base de datos"... sobre todo cuando casca y descubres que la replica se jodio hace un mes por una ligera desconexion de red, y no hay nada para poder restaurar los datos perdidos... :(
    [ Padre ]
  • por canuto (3359) el Sábado, 26 Abril de 2003, 21:58h (#178706)
    En un gestor de bases de datos están reñidos la funcionalidad y el rendimiento. Es fácil comprender que las transacciones serán más rápidas si no necesitan comprobar nigún "constraint", ni desencadenar ningún "trigger". Así mismo, será también más rápida una consulta si no existe "integridad referencial". Lo difícil es encontrar una buena síntesis entre funcionalidad y prestaciones, y la bondad de este compromiso depedenderá de la labor específica a la que esté orientado dicho gestor.

    Y digo yo, ¿no sería posible que estuviesen disponibles la integridad referencial, triggers, ... y que se pudieran activar o desactivar en el momento de la compilación? De esta forma, si no necesitamos de estas características, al desactivarlas ganamos en velocidad, pero si las necesitamos recompilamos y ya está.

    Yo tengo experiencia con PostgreSQL y solía utilizar integridad referencial, pero no utilizaba ni triggers ni procedimientos almacenados, así que desactivando estas opciones en tiempo de compilación podría obtener una mejora en el rendimiento.

    De todas formas, no sé esa mejora de rendimiento sería tan significativa como para merecer la pena implemnetarla.
    [ Padre ]
  • por pobrecito hablador el Domingo, 27 Abril de 2003, 11:19h (#178741)
    Tendra sus ventajas pero mySql no es suficiente para trabajar con datos criticos, no es ACID 'compliant' (atomicity, consistency, isolation and durability), o por lo menos no lo era aunque creo que hay algun metodo para que si lo sea, pero me imagino que entoncen ya pierdes agilidad y sencillez.

      No es cuestion de simpatias, gustos u opiniones, es simplemente lo que hay. MySql no tiene lo que un gestor de bases de datos tiene que tener. Al hacer segun que operaciones en multiples tablas te juegas la integridad de los datos, asi de simple.

      Discrepo tambien en que la mayoria de gestores de bbdd no necesitan muchas de las funcionalidades de gestores como oracle. Esas 'funcionalidades' que tal vez tu no usuas influyen directamente en la seguridad y sencillez del codigo y si sabes usarlas (no es sencillo, como muchas otras cosas) te proporcionan gran potencia y ayudan a que la aplicacion sea mas robusta y mas rapida.

    El rendimiento no tiene que conseguirse a costa de la seguridad nunca. Si necesitas mas rendimiento lo mas logico, sencillo y normamente barato (despreciable) es mejorar el hardware.

      MySql esta para lo que esta y tendra sus ventajas en algunas situaciones, pero no lo confundamos con lo que no es.

     
    [ Padre ]