Conviviendo con el motor Federated de MYSQL
Para quien no conozca el motor federated de Mysql, es mas o menos lo siguiente:
Se tiene una tabla T1 en el servidor S1. En el servidor S2, se necesita “ver” los datos de la tabla T1. Si se trabaja con Mysql, se tienen dos opciones:
1. Unirlas mediante programacion
2. Crear una tabla federada en S2, apuntando hacia S1.
La tabla federada en S2, actua exactamente como si estuviese almacenada en S2, aun cuando los datos están almacenados en S1. Desde la bd en S2, es posible realizar inserts, updates y deletes con normalidad.
Por lo que he leído en otras webs, el motor Federated no es al 100% fiable, aun así, tengo que decir que tengo algunas aplicaciones utilizando este tipo de tablas, con consultas y actualizaciones realizadas varias veces por ida, y no he tenido ni un solo problema. De allí, puedo decir que quizás no sean una buena opción para aplicaciones mayores, pero en sistemas pequeños, suelen ser muy funcionales, y pueden ahorrarnos varias lineas de código en las aplicaciones.
Mas informacion sobre tablas federadas en
Sebastian Thrun – University 2.0 – Udacity
http://new.livestream.com/channels/556/videos/112950
En el enlace, se encuentra el discurso de Sebastian Thrun en el cual reflexiona sobre los metodos utilizados por las universidades en la actualidad. En resumen, habla de sus experiencias durante el curso impartido en 2011 a través de www.ai-class.com en compañía de Peter Norvig. Durante el discurso, la conclusión central es que Sebastian no encuentra como volver a dar clases para 15 o 20 personas en un salon de clases, cuando puede compartir sus conocimientos con miles y miles alrededor del mundo. Es por ello que lanza el proyecto Udacity, sitio en el cual se ofrecen de momento 2 cursos en linea:
Computer Science 373: Programming a Robotic Car
Computer Science 101: Building a Search Engine
Ambos cursos inician el 20 de febrero próximo.
Es muy interesante la propuesta. El sitio de udacity ofrece que en 7 semanas, enseñaran como programar un motor de búsqueda como google o yahoo y por el otro lado, en las mismas 7 semanas, podria aprenderse a programar todos los sistemas de un auto-robot.
Oportunidades para no dejar pasar.
Lentitud en lecturas de SISS 2008
Hace algunos días, trabajando con SISS 2008, experimentaba una extrema lentitud al ejecutar un paquete de migración de datos, exactamente cuando se esta pre-ejecutando el paquete. La razón?: Los indices utilizados por el dbms al ejecutar la consulta sobre el origen de datos. Es curioso, pues la consulta ejecutada sobre la base de datos en si, devuelve resultados rápidamente, pero al ejecutar se desde siss, se toma mucho tiempo (20 o 30 minutos, mientras que ejecutada directamente son 2 minutos a lo sumo).
Conclusion: Al trabajar con siss (al menos el 2008), es completamente necesario que las consultas utilicen indices en la base de datos origen.
