Hola a todos.
Estoy intentando cambiar la forma de trabajo que vengo usando para manejar colecciones de datos y decidí volver a probar (otra vez   ) con las matrices de dos dimensiones, es decir una matriz donde cada elemento de esta es a su vez otra matriz.
Hice este ejemplo para probar y si bien logre crear, recuperar y modificar elementos no doy con la forma de buscar por algún elemento anidado.



Si alguno ya lo ha solucionado me vendría bien esa experiencia, muchas gracias.

Les juro que he visto un montón de posts de este tema y no logro resolverlo en un caso práctico para aplicarlo.

Saludos.

Tincho:

Con estructura de datos complejos, yo suelo trabajar con Variant[] y dentro de ellas  Colecciones

Te dejo un ejemplo.

 

Esta forma de trabajar, te permite crear estructuras de datos muy complejos, ya que los Variant[] pueden contener otros Variant y/o Colecciones y estas a su vez más Variant/Colecciones.

Ademas suelo crear listas de cadenas con las "Key", de las colecciones, para realizar búsquedas de los datos.

Para guardar estas estructuras de datos "complejas", las convierto en formato  json.

Un ejemplo "real", es una aplicación que estoy terminando que se llama bingoedu:
https://github.com/jsbsan/bingoedu

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Creo que cuando vamos a tratar o crear una estructura de datos para nuestro programa, mas que usar una u otra,
debemos usar la que más nos convenga y la facilidad a la hora de trabajar con ella.

No es lo mismo hablar de coordenadas  que el manejo de los datos de un cliente.
Luego tambien hay que tener en cuenta, el volumen de datos que vamos a manejar.
Si es pequeño quizás no necesitemos una base de datos.

El anidamiento que puede crearse dentro de la estructura puede llegar a ser bastante complejo.

En el ejemplo de las provincias de Andalucía, podíamos haber querido especificar cuales tienen costa.
La estructura se puede ir complicando. ¿ Hasta que nivel queremos complicarnos ?.
¿ Es necesario llegar a un nivel tan complicado ?.

Llegará un momento que lo mejor será una base de datos.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shell escribió: [Ver mensaje]

...Llegará un momento que lo mejor será una base de datos.

En mi caso, uso las listas de dos dimensiones para el manejo de información de configuración que se apoya en gb.settings generalmente para guardar y recuperar dicha información o, menos frecuentemente en bases de datos. Esta configuración se lee una vez al inicio del programa y luego se cambia en la dichosa lista bidimensional, y al finalizar el programa se guarda lo que haya cambiado para que la próxima vez todo este como lo dejamos.

Luego esta la información que se maneja en el programa y que pertenece al conjunto de los "datos" que no esta relacionados con la configuración o el funcionamiento sino con el trabajo que se hace con el programa, como puede ser coordenadas, materiales, almacén, direcciones de contactos etc. en ese punto esta claro que una base de datos el lo suyo, opino.

Saludos.

Citar:

En mi caso, uso las listas de dos dimensiones para el manejo de información de configuración que se apoya en gb.settings generalmente para guardar y recuperar dicha información o, menos frecuentemente en bases de datos. Esta configuración se lee una vez al inicio del programa y luego se cambia en la dichosa lista bidimensional, y al finalizar el programa se guarda lo que haya cambiado para que la próxima vez todo este como lo dejamos.

Tal cosa he hecho yo durante muchos años, y aún tengo rulando programas que hacen eso. Sin embargo un día me dí cuenta que la diferencia entre el tiempo de reacción de settings y el tiempo de consulta de una variable no tienen importancia ninguna si tienes en cuenta que normalmente se leen una vez al empezar y luego esporádicamente al bucar un path o algo así. Si un valor de settings se cambia, se almacena en el momento. Si un valor de settings se usa en un bucle (donde sería de tener en cuenta esa diferencia) lo paso a una variable local antes del bucle y punto.

===================
No podemos regresar

shordi escribió: [Ver mensaje]

Tal cosa he hecho yo durante muchos años, y aún tengo rulando programas que hacen eso. Sin embargo un día me dí cuenta que la diferencia entre el tiempo de reacción de settings y el tiempo de consulta de una variable no tienen importancia ninguna si tienes en cuenta que normalmente se leen una vez al empezar y luego esporádicamente al bucar un path o algo así. Si un valor de settings se cambia, se almacena en el momento. Si un valor de settings se usa en un bucle (donde sería de tener en cuenta esa diferencia) lo paso a una variable local antes del bucle y punto.

Si, comprendo perfectamente lo que decis. y eso de mantener simple "kiss".
En mi caso, cada vez que cambio la tabla en un treeview por ejemplo, el grid debe modificar los datos y las columnas, y leer unos 300 datos de promedio para buscar ajustar y acomodar todo óptimamente, así que lo de leer esporádicamente el gb.settings no se aplicaría en este caso.

Pero créeme que he llegado a este método porque eso es justamente lo que busco, simplificar las cosas. Cuando comienzo un programa con bases de datos, por mas que planifique y diseñe la base siempre surge algo nuevo o algo para optimizar. Luego está el tema de manejar los títulos de los campos en el GridView y Label y que además se puedan traducir a los otros idiomas. también está el tema de importación y exportación de datos en los que los .csv o similares no siempre van a coincidir en el orden exacto de las columnas de la base o el grid.
Bueno, finalmente toda esta "Meta" información accesoria a la base y se guarda en gb.settings como sitio "natural " en gambas pero cuando la cantidad de campos es grande....
Supongamos el caso práctico de una agenda de contactos modesta que usa claves foráneas y tiene un total de 30 campos entre todas las tablas y 30 campos más para las vistas de estas tablas para que en el grid en vez de aparecer números aparezcan palabras (en el caso de foráneas). Eso nos deja en 60.

Si tenemos 10 parámetros para cada campo eso nos da un total de 600 valores para manejar con gb.settings, lo cual implica buscar ordenar y modificar.
Gb.Settings + 20variables
Si nos manejamos solo con gb.settings eso nos da 10 variables para todos los parámetros cada vez que cambiamos de campo, y, digamos, 5 variables mas para cada vez que ese campo sea foráneo podríamos estimar en 20 variables solo para los metadatos de cada campo que el bucle del evento Data_ o de creación de controles para editar registros o de importación / exportación de datos etc. etc.
En este caso se usan muchas variables y si se quiere extender hay que crear más variables.

Gb.Settings + 1 variables bidimensional
Para los mismos metadatos, con solo una variable [0,1,2,...,n] se pueden gestionar todos estos y si se quiere extender es una posición más de esta, sin tener que crear más variables. El código es mas limpio y sencillo y se puede estandarizar la forma de trabajo para varios programas, acelerando la creación de programas eficientes ya que leer y escribir en memoria siempre es más rápido que en disco, por lo menos de momento.

Saludos.

Es que settings no es para eso. Realmente creo que te complicas innecesariamente.

Citar:

Cuando comienzo un programa con bases de datos, por mas que planifique y diseñe la base siempre surge algo nuevo o algo para optimizar.

¿ ?

Citar:

Luego esta el tema de manejar los títulos de los campos en el GridView y Label y que ademas se puedan traducir a los otros idiomas.

¿Qué problema hay? para eso están los nombres de campo o las cabeceras de columna.

Citar:

también esta el tema de importación y exportación de datos en los que los .csv o similares no siempre van a coincidir en el orden exacto de las columnas de la base o el grid.

¿Por qué no?    

===================
No podemos regresar

shordi escribió: [Ver mensaje]

Es que settings no es para eso. Realmente creo que te complicas innecesariamente.

Citar:

Cuando comienzo un programa con bases de datos, por mas que planifique y diseñe la base siempre surge algo nuevo o algo para optimizar.

¿ ?

Citar:

Luego esta el tema de manejar los títulos de los campos en el GridView y Label y que ademas se puedan traducir a los otros idiomas.

¿Qué problema hay? para eso están los nombres de campo o las cabeceras de columna.

Citar:

también esta el tema de importación y exportación de datos en los que los .csv o similares no siempre van a coincidir en el orden exacto de las columnas de la base o el grid.

¿Por qué no?    

Que quieres que te diga, para gustos los colores.   .

Saludos.