Conjuntos versus Almacenes de datos

[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.

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, una función, un conjunto ni un NameBlock. Estos tipos abstractos quizás se podrían almacenar como expresiones evaluables.

También se podría hacer un almacenamiento especial bastante eficaz para conjuntos, estructurados o no, cuyos campos sean todos no abstractos y para vectores de los mismos, es decir, las típicas tablas que se almacenan en archivos BST o bases de datos.

Incluso cabría la posibilidad de asignar modos de almacenamiento virtual de forma que los datos no residieran físicamente en memoria sino en archivos en disco o bases de datos, aunque esto supondría que los objetos sirvieran únicamente para lectura secuencial.

Tratar de extender el actual tipo Set a estos conceptos tal vez resultase demasiado complicado 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

Este nuevo tipo tendría una enorme utilidad como puente para el almacenamiento masivo de información en archivos de texto, bases de datos y OIS.

También podría ser la base de una nueva forma de serialización orientada al transporte de información entre aplicaciones TOL remotas.

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 ​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 [​en memoria que podría ​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.
• Array: Si los datos son una simple lista ordenada de objetos no abstractos distintos de Data, entonces se puede almacenar en una tabla con un campo indicador del tipo TOL y otro campo sin tipo fijo, una característica interesante de Sqlite ​Manifest typing
• Tree: Si los datos se organizan de forma arbitraria es necesario tener una tabla de objetos y otra de relaciones de pertenencias.

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.