id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
1070	Conjuntos versus Almacenes de datos	Víctor de Buen Remiro	Víctor de Buen Remiro	"Los conjuntos en TOL representados por el tipo ""Set"" son internamente un array de punteros a objetos TOL con algo más de ''overhead'' para el manejo de {{{Struct}}}, {{{NameBlock}}} y otros temas.

Esta representación exhaustiva es muy flexible y potente pero unida a la gran cantidad de información adjunta a todo objeto TOL produce un gran aumento del tamaño de la memoria cuando se manejan conjuntos grandes.

Para ciertos tipos de conjuntos que se utilizan muy a menudo podría pensarse en un método de representación interna más eficiente. Por ejemplo, un conjunto que sólo tuviera números sería mucho más eficaz  almacenarlo como un vector de elementos de tipo {{{double}}}. No existiría un objeto TOL para cada elemento sino que sólo cuando se accediera al mismo se crearía el objeto {{{Real}}} con el valor correspondiente. 

Evidentemente esto tiene un precio, pues no sería posible acceder por nombre a un conjunto como éste, ni tampoco podría añadírsele con {{{Append}}} algo que no fuera un número. Está claro que se necesita algo más flexible y potente que un mero array.

En lugar de número podría albergar textos, fechas, matrices o cualquier tipo TOL no abstracto, pero nunca podría albergar una serie temporal infinita, un conjunto temporal, una función, ni un {{{NameBlock}}}. Estos tipos abstractos quizás se podrían almacenar como expresiones evaluables. El problema de estos tipos de datos es que no son autodefinidos, sino que requieren referencias a otros objetos creados previamente, por lo que no se pueden consultar ni modificar de forma aleatoria sino únicamente en un hilo secuencial.

Tratar de extender el actual tipo {{{Set}}} a estos conceptos tal vez resultase demasiado complicado, aunque aún no se debe descartar,  debido a las restricciones de las operaciones realizables, por lo que quizás sería más sensato crear un nuevo tipo {{{Data}}} que podría albergar sólo elementos de tipos no abstractos incluido el propio {{{Data}}}. 

También cabe la posibilidad de no implementar un nuevo tipo sino que sea sólo una API, un conjunto de métodos que permitan manejar la información de una forma eficaz y sencilla de manejar y que los almacenes se identifiquen mediante un puntero interno visible en TOL como un {{{Real}}} igual que se hace ahora con los archivos {{{Excel}}} y otros sistemas.

En cualquier caso llamaremos {{{Data}}} al sistema que implemente estas ideas, y ya se verá después el formato. Este nuevo sistema sería en sí mismo una forma de serialización y tendría una enorme utilidad como puente para el manejo masivo de información en 
 * ''memoria'': Debe ser tan fácil de usar como lo es el Set actualmente, tanto en creación como en consulta y modificación.
 * ''archivos'': Debe ser almacenable y legible a y desde disco de una forma natural. Este es el método de almacenamiento persistente más sencillo y más adecuado a un entorno local.
 * ''bases de datos'': Debe ser insertable en un campo blob de una base de datos remota. Se trata de un método de almacenamiento persistente más complicado que el archivo pero mucho más seguro y fácil de usar en un entorno de desarrollo compartido. Sólo es necesario implementar en TOL un mecanismo para inserción y lectura de datos blob, ay que actualmente esto sólo se puede hace mediante codificación en Base64.
 * ''comunicaciones'': Debe ser transmisible vía tcpip al menos entre procesos TOL, pero no estaría de más que otros procesos fueran capaces de crearlos o entenderlos.

Habría que considerar la posibilidad de que el método de almacenamiento de este tipo de datos, o al menos uno de los métodos, fuera [http://www.sqlite.org/index.html Sqlite] embebido en C++, pues esto permitiría abstraerse de toda la complejidad del almacenamiento, altas, bajas y modificaciones del contenido. Sqlite es una base de datos que se almacena en un único fichero por lo que es ideal para los objetivos planteados. Cada objeto de tipo {{{Data}}} podría implementarse como una base de datos [[http://www.sqlite.org/inmemorydb.html en memoria] que podría [http://www.sqlite.org/backup.html salvarse en disco] en cualquier momento.

En cuanto a la estructura de los objetos dentro del {{{Data}}} podrían plantearse varios tipos que dieran la mayor flexibilidad:
 * ''Table'': Cuando los datos que se quieren almacenar son simplemente registros estructurados de forma homogénea, es decir, cada elemento es un a su vez un {{{Data}}} con una estructura fija, el objeto puede ser almacenados como una simple tabla sin más.
 * ''Tree'': Si los datos se organizan de forma arbitraria es necesario tener una tabla de objetos y otra de relaciones de pertenencias. En la primera habría un campo identificador numérico, otro de nombre, un indicador del tipo TOL y otro campo de contenido  sin tipo SQL prefijado, una característica interesante de Sqlite [http://www.sqlite.org/different.html Manifest typing], que permite asignar un tipo distinto a cada valor.

"	task	new	low	Mantainance	SetAlgebra		minor