close Warning: Can't synchronize with repository "(default)" (/var/svn/tolp does not appear to be a Subversion repository.). Look in the Trac log for more information.

Changes between Version 4 and Version 5 of Ticket #1070


Ignore:
Timestamp:
Jan 24, 2011, 11:36:18 AM (14 years ago)
Author:
Víctor de Buen Remiro
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1070 – Description

    v4 v5  
    1 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.
     1Los 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.
    22
    33Esta 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.
    … …  
    55Para 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.
    66
    7 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.
     7Evidentemente 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.
    88
    9 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.
     9En 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.
    1010
    11 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.
     11Tratar 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}}}.
    1212
    13 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.
     13Tambié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.
    1414
    15 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}}}
    16 
    17 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.
    18 
    19 También podría ser la base de una nueva forma de serialización orientada al transporte de información entre aplicaciones TOL remotas.
     15En 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
     16 * ''memoria'': Debe ser tan fácil de usar como lo es el Set actualmente, tanto en creación como en consulta y modificación.
     17 * ''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.
     18 * ''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.
     19 * ''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.
    2020
    2121Habrí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.
    … …  
    2323En cuanto a la estructura de los objetos dentro del {{{Data}}} podrían plantearse varios tipos que dieran la mayor flexibilidad:
    2424 * ''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.
    25  * ''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 [http://www.sqlite.org/different.html Manifest typing]
    26  * ''Tree'': Si los datos se organizan de forma arbitraria es necesario tener una tabla de objetos y otra de relaciones de pertenencias.
     25 * ''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.
    2726
    28 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.