Gráficos grandes en Access
Supongo que a casi todo el mundo próximo a los PC le suena Access, la base de datos que forma parte del paquete MS Office.
No hace falta ser usuario de Windows para estar al tanto de ella ya que es uno de los puntos algo flacos de programas libres como OpenOffice y por tanto una de los campos a cubrir. No me voy a meter en este rollo, porque ya sabemos de qué lado estoy, pero es importante perfilar algunos datos.
Las ventajas de Access y semejantes no van precisamente por el lado de la potencia y eficiencia a la hora de manejar grandes conjuntos de datos y sí por la facilidad y rapidez de creación y mantenimiento de sistemas de bases de datos simples completos. Sus capacidades abarcan el diseño del conjunto de tablas y sus relaciones, la creación y mantenimiento de consultas, interfaces de entrada de datos, generación de informes, importación y exportación de datos, automatización... Un poco de todo, nada a nivel óptimo, pero realmente útil para una gran mayoría de aplicaciones pequeñas. Hace muy fácil lo fácil y muy difícil lo difícil.
En el caso concreto de Access, una de las limitaciones que más me choca es el pobre sistema de generar gráficos que posee, precisamente porque es una de las cosas que se hacen constantemente en entornos de oficina. Admite una buena colección de tipos de gráficos distintos, pero sus opciones son poco configurables y menos en tiempo de ejecución. No admite por ejemplo el cambiar el tamaño del gráfico en función del número de elementos que tenga que representar o crear varios gráficos separados si se trata de muchos datos para mejorar la legibilidad; al menos no de forma clara, y la ayuda (F1) no es de mucha ayuda :-P . En general la documentación es algo deficiente y de no ser por los abnegados colaboradores de los grupos de noticias sería infernal hacer gran cantidad de cosas.
Bueno, pues al menos para este problema que he tenido con los gráficos estoy utilizando una salida rápida: particionar el conjunto de datos de entrada en bloques que utilizo para generar varios gráficos. Ayudaría que SQL fuese, además de estructurado, estándar, pero no es el caso. Menos mal que hay quien se preocupa por ver cómo trabajar entre dialectos y hace, por ejemplo, la emulación de LIMIT OFFSET en varios tipos de base de datos. De hecho se trata de un módulo de Perl creado para generar SQL de forma intuitiva y flexible, pero a mí me vale su estudio porque estupendamente documentado. Me encanta el software libre.
No hace falta ser usuario de Windows para estar al tanto de ella ya que es uno de los puntos algo flacos de programas libres como OpenOffice y por tanto una de los campos a cubrir. No me voy a meter en este rollo, porque ya sabemos de qué lado estoy, pero es importante perfilar algunos datos.
Las ventajas de Access y semejantes no van precisamente por el lado de la potencia y eficiencia a la hora de manejar grandes conjuntos de datos y sí por la facilidad y rapidez de creación y mantenimiento de sistemas de bases de datos simples completos. Sus capacidades abarcan el diseño del conjunto de tablas y sus relaciones, la creación y mantenimiento de consultas, interfaces de entrada de datos, generación de informes, importación y exportación de datos, automatización... Un poco de todo, nada a nivel óptimo, pero realmente útil para una gran mayoría de aplicaciones pequeñas. Hace muy fácil lo fácil y muy difícil lo difícil.
En el caso concreto de Access, una de las limitaciones que más me choca es el pobre sistema de generar gráficos que posee, precisamente porque es una de las cosas que se hacen constantemente en entornos de oficina. Admite una buena colección de tipos de gráficos distintos, pero sus opciones son poco configurables y menos en tiempo de ejecución. No admite por ejemplo el cambiar el tamaño del gráfico en función del número de elementos que tenga que representar o crear varios gráficos separados si se trata de muchos datos para mejorar la legibilidad; al menos no de forma clara, y la ayuda (F1) no es de mucha ayuda :-P . En general la documentación es algo deficiente y de no ser por los abnegados colaboradores de los grupos de noticias sería infernal hacer gran cantidad de cosas.
Bueno, pues al menos para este problema que he tenido con los gráficos estoy utilizando una salida rápida: particionar el conjunto de datos de entrada en bloques que utilizo para generar varios gráficos. Ayudaría que SQL fuese, además de estructurado, estándar, pero no es el caso. Menos mal que hay quien se preocupa por ver cómo trabajar entre dialectos y hace, por ejemplo, la emulación de LIMIT OFFSET en varios tipos de base de datos. De hecho se trata de un módulo de Perl creado para generar SQL de forma intuitiva y flexible, pero a mí me vale su estudio porque estupendamente documentado. Me encanta el software libre.
No hay comentarios:
Publicar un comentario