La serialización consiste en convertir en una cadena un objeto en concreto, es así como congelar un objeto en un momento de su vida. Este objeto se puede recuperar desde la cadena serializada en cualquier momento recuperando su estado.
Generalmente siempre que utilizamos un objeto lo declaramos, lo usamos y lo destruimos, casi nunca nos preocupamos en quedarnos con algún estado de su vida. En todo caso, solemos grabar propiedades de este en bases de datos o ficheros para poder construir otro objeto en otro momento. Con la serialización logramos obtener el estado de un objeto para manipularlo con posterioridad. Por ejemplo, en un administrador podríamos grabar el estado actual para poder recuperarlo más tarde y permitir que el usuario siguiese el trabajo en el punto donde lo dejó.
Otro caso interesante sería aquel en el que un objeto casi siempre tiene los mismos valores y estos resultan caros de obtener. Este costo puede ser debido a acceso a bases de datos o cálculos intermedios. Esto es más sangrante en lenguajes como PHP donde se pierden todos los objetos una vez que terminamos el script.
La serialización es una buena solución, podemos construir el objeto una vez, lo usamos y antes de destruirlo lo serializamos. Más tarde en vez de tener que volver a tener que hacer accesos a recursos costosos lo único que tenemos que hacer es recuperar la el objeto serializado.
Como el objeto no se actualiza de manera frecuente sólo tendremos que repetir el proceso de serialización en los casos en los que variemos los datos de estos.
Por ejemplo, si tenemos un sistema de traducción en una página la forma habitual de trabajar es primero construyendo un vector o un objeto que almacene todas las traducciones para esta página. Estos datos los sacaremos de una base de datos e utilizaremos el objeto como caché. Una vez que terminemos el script, eliminamos el objeto.
Esto se repetirá una y otra vez cada vez que ejecutemos el script con sus constantes accesos a la base de datos. Una solución basada en la serialización sería la siguiente: cuando se ejecuta el script creamos el objeto basado en un serialización previa, en el caso de que la página fuese modificada tendríamos que acceder a la base de datos , modificar el objeto y por último antes de eliminar el objeto seriarlo y grabarlo de nuevo.
De esta manera ahorraremos una gran cantidad de accesos al motor de base de datos y ahorraremos una gran cantidad de recursos.
Escribiéndolo en un algoritmo informal:
si tenemos fichero serializado
creamos buffer en base al fichero
sino
creamos buffer vacio
finsi
para todas las claves del documento
buscamos en el buffer
si esta en el buffer
recuperamos palabras del buffer
sino
hacemos peticion a base de datos
finsi
finpara
si buscamos algo en base de datos
serializamos el buffer
grabamos fichero con la cadena serializada
finsi
Generalmente siempre que utilizamos un objeto lo declaramos, lo usamos y lo destruimos, casi nunca nos preocupamos en quedarnos con algún estado de su vida. En todo caso, solemos grabar propiedades de este en bases de datos o ficheros para poder construir otro objeto en otro momento. Con la serialización logramos obtener el estado de un objeto para manipularlo con posterioridad. Por ejemplo, en un administrador podríamos grabar el estado actual para poder recuperarlo más tarde y permitir que el usuario siguiese el trabajo en el punto donde lo dejó.
Otro caso interesante sería aquel en el que un objeto casi siempre tiene los mismos valores y estos resultan caros de obtener. Este costo puede ser debido a acceso a bases de datos o cálculos intermedios. Esto es más sangrante en lenguajes como PHP donde se pierden todos los objetos una vez que terminamos el script.
La serialización es una buena solución, podemos construir el objeto una vez, lo usamos y antes de destruirlo lo serializamos. Más tarde en vez de tener que volver a tener que hacer accesos a recursos costosos lo único que tenemos que hacer es recuperar la el objeto serializado.
Como el objeto no se actualiza de manera frecuente sólo tendremos que repetir el proceso de serialización en los casos en los que variemos los datos de estos.
Por ejemplo, si tenemos un sistema de traducción en una página la forma habitual de trabajar es primero construyendo un vector o un objeto que almacene todas las traducciones para esta página. Estos datos los sacaremos de una base de datos e utilizaremos el objeto como caché. Una vez que terminemos el script, eliminamos el objeto.
Esto se repetirá una y otra vez cada vez que ejecutemos el script con sus constantes accesos a la base de datos. Una solución basada en la serialización sería la siguiente: cuando se ejecuta el script creamos el objeto basado en un serialización previa, en el caso de que la página fuese modificada tendríamos que acceder a la base de datos , modificar el objeto y por último antes de eliminar el objeto seriarlo y grabarlo de nuevo.
De esta manera ahorraremos una gran cantidad de accesos al motor de base de datos y ahorraremos una gran cantidad de recursos.
Escribiéndolo en un algoritmo informal:
si tenemos fichero serializado
creamos buffer en base al fichero
sino
creamos buffer vacio
finsi
para todas las claves del documento
buscamos en el buffer
si esta en el buffer
recuperamos palabras del buffer
sino
hacemos peticion a base de datos
finsi
finpara
si buscamos algo en base de datos
serializamos el buffer
grabamos fichero con la cadena serializada
finsi
Comentarios