En la publicación anterior comenté algo sobre "eficiencia" y es porque estoy convencido que los desarrolladores siempre debemos tener esa palabra en mente; ahora vamos a realizar un ejercicio en el que implementaremos un DataSet con varias tablas, relaciones y además utilizaremos el Cache del servidor ASP para mantener los datos.

En la parte 4 de esta serie de publicaciones hicimos una implementación "económica" para acceder a la información de Provincias, Departamentos y Localidades permitiendo que el usuario seleccione los distintos ítems hasta obtener una Localidad en particular. Digo económica porque utilizamos objetos del tipo SqlDataReader que son más chicos y más rápidos que los DataSet, sin embargo cada vez que un usuario accede a todo el proceso de selección de una localidad se producen innumerables accesos al motor de la base de datos.

Ocurre que la información de Provincias, Departamentos y Localidades rara vez cambia (casi nunca) de manera que esta información es una excelente candidata para ser "cacheada" en RAM evitando de ese modo miles de accesos al servidor de datos. Por supuesto habrá que pensar algún mecanismo para actualizar el cache, lo que dejo para el final de esta publicación.

Por otro lado, lo que vamos a realizar es un objeto complejo que tendrá toda la información necesaria para brindar a cualquier usuario los datos de acuerdo a la selección que va realizando. Esto quiere decir que este objeto complejo tendrá toda la información de Provincias, Departamentos y Localidades con las relaciones necesarias para realizar el filtrado de datos correspondiente.

More...

With XML and object technologies, some people wonder whether the relational model is obsolete.

Many developers looking for greater flexibility feel that their choices are very limited with the relational model.

Some people think that storing everything in XML format bridges the gap between objet-oriented applications and relational databases. However, in many cases people are just reinventing the wheel.

The relational model is limiting, you need constraints to enforce data integrity. In XML data type structure is more relaxed but it exist.

XML schemas are volatile for some business cases, but quite stable for some situations. Not being able to find a structure that suits a business problem dos not mean that such a structure does not exist.

I do not want to think that I am totally against having the support of XML in a relational database.

You should use an XML model if your data is sparse, it means having many unknown values, or if some columns (fields) are not applicable to all rows (records). Solution for this problem is introduce subtypes or implement an open schema in relational environment. A solution that introduces subtypes can lead to many new tables, a solution with relational open shcema can lead to complex, dynamic SQL statements. A solution based on XML could be the easist to implement.

Finally, today we have engines relational databases that allow storing XML data, which allows us to definitively as computer professionals make the best choice when it comes to designing a solution.

Personally I think that stay with engines database that not have this feature, means to stay in the past. We face the development of the Semantic Web and we are preparing for the Web 3.0; engine databases must evolve.

Con XML y la tecnología de objetos, algunos se preguntan si el modelo relacional es obsoleto.

Muchos desarrolladores en la búsqueda de una mayor flexibilidad creen que sus opciones son muy limitadas con el modelo relacional.

Algunos piensan que almacenar todo en formato XML, reduce la diferencia entre las aplicaciones orientadas a objetos y las bases de datos relacionales. Sin embargo en muchos casos solamente están reinventando la rueda.

El modelo relacional es limitante, se necesitan límites para cumplir con la integridad de los datos. En XML, la estructura de datos es más relajada pero existe.

Los esquemas de XML son bastante volátiles para los negocios pero muy estables en otras situaciones. No ser capaz de encontrar una estructura que se adapte a un problema de una empresa, no significa que esa estructura no exista.

No quiero que piensen que estoy totalmente en contra de tener el apoyo de XML dentro de una base de datos relacional.

Debería utilizarse un modelo XML si los datos son escasos, esto es tener muchos valores desconocidos, o columnas (campos) que no son aplicables a todas las filas (registros). La solución para este problema es introducir subtipos o aplicar un esquema abierto en el modelo relacional. Una solución que introduce subtipos puede llevar a tener muchas nuevas tablas, con una solución de esquema abierto en el modelo relacional puede conducir a sentencias SQL dinámicas y complejas. Una solución basada en XML podría ser lo mejor.

Finalmente; hoy tenemos motores de bases de datos relacionales que permiten almacenar datos XML, lo que definitivamente nos permite como profesionales de la informática realizar la mejor elección a la hora de diseñar una solución.

Personalmente considero que permanecer con motores de base de datos que no lo permiten significa permanecer en el pasado. Enfrentamos el desarrollo de la Web Semantica y nos estamos preparando para la Web 3.0 los motores de bases de datos deben evolucionar.

He implementado el código necesario en los proveedores de XML y SQL para dar soporte al esquema de widgets en BlogEngine.NET, con esto tanto la zona de widgets como los widgets mismos se pueden almacenar en la base de datos o en archivos XML.

La estratégia utilizada es mantener el formato XML de cada uno de estos elementos y almacenarlos de ese modo en la base datos, obviamente esto solo funciona en SQL Server 2005 o superior.

Todos los cambios y agregados se encuentran en el archivo BlogEngine.zip (47,01 kb). En el se mantiene la estructura de directorios del proyecto original, de modo que sabrán donde deben copiar cada uno de los archivos, esta probado con el conjunto de cambios 10287.

También están los widgets que faltan en la versión 1.3, se puede probar  en este lugar, de hecho con el usuario y password estándard.

Nota: al 25-Mar-2008, el equipo de desarrollo de BlogEngine está implementando un soporte en los proveedores de XML y SQL para widgets, themes y extensiones. Es conveniente esperar por esta versión.

 

I implemented the necessary code in XML and SQL providers to support widgets schema in BlogEngine.NET, so widgetzones and widgets themselves can be stored in the database, or XML files.

The strategy used is to keep the XML format in each of these elements and store them in this way in the database, obviously this only works in SQL Server 2005 or higher.

All changes and additions are in the file BlogEngine.zip (47,01 kb). I maintain the directory structure of the original project, so you know where to copy each file, I tried this with change set 10287.

They are some widgets missing in version 1.3, you can try here, use the standard user name and password.

Note: at Mar-25-2008, BlogEngine developers team are implementing support in XML and SQL providers for widgets, thems and extensions. Is advisable to wait for this version.