En los dos primeras entregas, #1 y #2 hemos visto algunos pequeños elementos que harán mejorar de una forma bastante importante nuestras aplicaciones usando ADO.NET EF, aunque para ello apenas hemos tenido que tocar nuestro código y/o nuestros modelos de entidades. En esta tercera entrega, veremos un ejemplo de una técnica de modelado de entidades que nos permitirá relajar ciertas consultas que pudieran representar un posible problema dentro de nuestras aplicaciones.
La técnica en cuestión se conoce como Table Spliting y básicamente consiste en poder separar los datos de una entidad, mapeada a una única tabla, en varias entidades con una relacion 1:1 entre las mismas. El primer ejemplo que vamos a ver , y uno de los en que mejor se puede ver la utilidad de esta técnica, consiste en el típico caso de una tabla con clientes en el que además se almacena la imagen del mismo, figura 1.
Si partimos de la base de datos para crear un modelo de entidades lógicamente ADO.NET EF creará por nosotros una entidad Customer que contega este campo Imagen como parte de la entidad. A partir de aquí cualquier consulta a esta entidad obtendrá de la base de datos este campo, a pesar de que en una aplicación normal las veces que realmente necesitemos el campo imagen sea infima con respecto al resto de consultas. Esto, lógicamente, puede tener un impacto fuerte, en primer lugar por el probable tráfico de datos que podemos transmitir por la red, si cada cliente tiene una imagen de 1MB y seleccionamos 1000 imágenes podemos mover a traves de la red 1000 MB presúntamente innecesarios.
Los pasos para realizar nuestro “Table Spliting” consiste en crear una nueva entidad, por ejemplo CustomerPicture, e incluir en esta el campo Imagen y el campo clave que nos permitirá realizar la asociacion entre esta entidad y la entidad Customer.
Una vez creada la asociación, establecemos correctamente el mapeo de la entidad CustomerPicture para mapearla con la tabla “customers”.
Como se puede observar en estos pasos a grosso modo, la técnica de table spliting es muy facil realizarla directamente en nuestros modelos y con la misma podemos obtener los resultados buscados.
Aunque en principio esta técnica le parezca que está restringida a estos casos tan particulares la realidad es que no es así. En muchas ocasiones, con modelos legacy, nos podemos encontrar con tablas con una gran cantidad de columnas. Las consultas a estas entidades, en EF como en cualquier otro framework ORM, siempre traen todos los campos de la tabla y esto podría provocar lentitud en las mismas si las tablas tienen bloqueos frecuentas, incluso aunque estas consultas tengan predicados con una correcta utilización de índices. Ante estos casos una posible solución es utilizar Table Spliting como acabamos de ver o bien realizar materializaciones parciales usando Tuple o tipos anónimos.
Saludos
Unai Zorrilla Castro
Después de una serie un poco grande de post sobre una temática concreta siempre está bien hacer una pequeña