Este foro usa cookies
Este foro utiliza cookies para almacenar su información de inicio de sesión si está registrado y su última visita si no lo está. Las cookies son pequeños documentos de texto almacenados en su computadora; las cookies establecidas por este foro solo se pueden usar en este sitio web y no representan ningún riesgo de seguridad. Las cookies en este foro también rastrean los temas específicos que ha leído y la última vez que los leyó. Si Ud. continúa navegando, entenderemos que acepta todas las cookies.

Se almacenará una cookie en su navegador, independientemente de la elección, para evitar que se le vuelva a hacer esta pregunta. Podrá cambiar la configuración de sus cookies en cualquier momento utilizando el enlace en el pie de página.

El foro antiguo se encuentra accesible desde https://foro.gambas-es.org en modo de solo lectura.

Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5

¿Cómo es la mejor forma? (Gestión de datos)
#1

Hola a todos.

Estoy inmerso en un programa para mi y me surge una duda. Para hacer un resumen, vamos a imaginar que tenemos una cuadrícula 6 x 4. Todos los datos almacenados en esa cuadricula son de tipo texto. Y todos esos datos pertenecen a una fecha concreta, es decir, hoy relleno esa cuadricula y mañana tengo que rellenarla con otros datos. Mi duda surge en como almacenar todo eso de forma correcta en una base de datos tipo SQLite3. He pensado en varias formas, pero no se cual es la más óptima, a la hora de liarme menos con el código, la más fácil a la hora de recuperar datos, etcétera.

Mi primera forma sería crear la base de datos con la fecha como identificador único y después todos los datos, pero claro, son muchas cuadrículas, tendría que ir 1x1, 1x2, 1x3, 1x4, 2x1, y así todo el tiempo.
Mi segunda forma sería, como la anterior, que la fecha sea el identificador único, y que solo creo las entradas de las columnas y las distintas filas, se vayan almacenando con un separador para después poderlo trocear (esta me parece la menos pragmática).
Y por último, ir creando por código tantas tablas como fechas vaya teniendo, y dentro de estas tablas almacenar todos los datos.

¿Cual creéis que es la mejor? ¿Alguna otra forma? Ya os digo que estoy pez en el diseño de base de datos.

Un saludo y muchas gracias.
    ¡Gracias!
#2

Yo lo haría de la forma más sencilla posible bajo mi punto de vista, que es la siguiente:

La tabla sólo tendría dos campos, fecha y datos.

Los datos los gestionaría como un array bidimensional, o quizás como una colección de arrays, o incluso como un array de arrays anidados. Me explico:

si tu tabla va a ser de 6x4 (6 columnas y 4 filas o al revés, 6 filas y 4 columnas ??) lo podríamos representar así:

Collection = [Fecha : [[0,1,2,3,4,5], [0,1,2,3,4,5],[0,1,2,3,4,5],[0,1,2,3,4,5]]]

Es decir, en una colección, lo que está a la izquierda de los ":" es la Key que debe ser un string, en este caso podría ser la fecha en el formato que prefieras, pero como cadena.

A la derecha de los dos puntos ":" está el valor asociado a esa llave (Key) del elemento de la colección, en nuestro caso, un array anidado que representa los 24 valores posibles ordenados por filas y columnas. Como el valor de los elementos de una colección es de tipo Variant, podemos meter ahí lo que queramos, así que nos sirve este array anidado que contiene otros 4 arrays (que corresponderían a las 4 filas, cada una con otro array de 6 elementos que serían las columnas). Visto de esta forma a golpe de vista parece más sencillo:

GAMBAS
  1. Collection = [Fecha : [
  2.                        [0,1,2,3,4,5],
  3.                        [0,1,2,3,4,5],
  4.                        [0,1,2,3,4,5],
  5.                        [0,1,2,3,4,5]
  6.                       ]
  7.              ]



Puede parecer lioso, pero es lo más básico y sencillo porque es lo más parecido a cómo se tratan los datos internamente en una tabla.

Lo cierto es que tanto para guardar como para recuperar los datos, deberás escribir métodos que vayan iterando a través de los elementos. No he tenido tiempo de hacerlo, pero usando Streams se pueden serializar datos del contenido de arrays en texto para almacenarlo en la base de datos y luego volver a recuperarlo convertido de nuevo en array, y ya mediante loops rellenar la cuadrícula de nuevo.

La otra opción es simplemente crear una tabla en la base de datos con tantos campos como columnas tengas y la fecha como un índice que no sea único, dado que para cada fecha tendrás tantas filas como sean necesarias y estarán repetidas. Para recuperarlas tendrías que usar la cláusula 'WHERE fecha = "tufecha"'.

En fin, no sé si me he explicado con suficiente claridad o te he liado más. Es un problema sencillo que quizás tenga otra solución también más sencilla que las que acabo de proponer...

Saludos

Por favor, usa el corrector ortográfico antes de pulsar el botón 'Enviar'
    ¡Gracias!
#3

Gracias jguardon.

 La primera parte de tu mensaje la tengo claro. No hay problema en el manejo del array.

Tu idea de repetir las fechas (recordemos que es una rejilla de 6 columnas por 4 filas, por lo tanto habría por cada día, cuatro fechas), también la he sopesado, aunque a priori me pareció una buena idea, después me pareció, como decirlo, poco elegante. Pero si, es otra opción más.

Un saludo.
    ¡Gracias!
#4

También podemos recurrir a una Clase con dos propiedades, Fecha y Datos. Cada fila es una instancia de esa clase y la tabla entera la puedes almacenar en un array de clases. Luego, mediante un interface (otra clase o un módulo) proveerías los métodos para almacenar, buscar u ordenar en una BD o en un fichero. 

Esta forma, más orientada a objetos, podría ser más comprensible y más flexible a su vez.

Saludos

Por favor, usa el corrector ortográfico antes de pulsar el botón 'Enviar'
    ¡Gracias!
#5

Me gusta tu idea, es elegante y sencilla de implementar y sobre todo de ampliar en caso de necesidad.

Muchas gracias.
    ¡Gracias!
#6

Hola Guinzas.
¿Para que es exactamente el programa?
¿Cuantos registros (fechas) manejara 100, 10000 ... ?
¿Querés usar una base de datos por alguna razón especifica?
¿Aceptás usar otros métodos de almacenamiento?
Se me ocurren algunas ideas pero sin saber para que es el programa no se si pueden se útiles.
Saludos.
    ¡Gracias!
#7

Hola tincho.

El programa es para uso personal. Se trata de rellenar cada día un parte de horas. Eso quiere decir, por poner un ejemplo, que el lunes de 8:00 a 10:00 he estado en tal sitio, de 10:00 a 12:00 en tal otro sitio y así todos los días. No todos los días estoy en los mismo sitio ni el mismo tiempo. Por eso pensé en el programa, que me ayude a llevar organizado las horas, que me calcule el tiempo que he estado en cada lugar (cosa que tengo que reflejar) y al final de la semana, que me imprima un parte de horas semanales. Cada día puedo estar, como mucho en seis sitios distintos,  y normalmente la jornada es de lunes a viernes, pero puede incluir sábado y/o domingo. En cada sitio que estoy, volviendo al ejemplo anterior de 8:00 a 10:00, lleva el tipo de trabajo que he realizado, el número asignado al sitio, el nombre, la hora de entrada, hora de salida y si esas horas son normales, extras o a recuperar.

 Había pensado en una base SQlite3 por facilidad a la hora de hacer búsquedas, de rellenar los datos, etcétera, y por que de momento las fechas son pocas (aun estoy puliendo el programa), pero dentro de unos cuantos meses, la cantidad de días son importantes, por eso había pensado en una base de datos.
Y claro que estoy dispuesto a usar otro método de almacenamiento, por supuesto, estoy abierto a escuchar ofertas Big Grin . Pensé que la base de datos era la forma mas sencilla.

 Un saludo.
    ¡Gracias!
#8

Bueno, luego de leer y mas o menos entender de que va tu programa, lo que te recomiendo es usar sqlite y una única tabla en la que registres cada visita.
Dado que la visita es el elemento único de tu programa no la fecha, ya que en la misma fecha podes tener varias visitas.
La sentencia de creación de la tabla seria algo así
CREATE TABLE IF NOT EXISTS `visitas` (
    `idx`    INTEGER PRIMARY KEY AUTOINCREMENT,
    `codigo`    TEXT UNIQUE,
    `fecha`    TEXT,
    `numero`    TEXT,
    `tipo`    TEXT,
    `entrada`    TEXT,
    `salida`    TEXT
);

Luego podes agregar todas las visitas que quieras a condición que el "codigo" sea único (lo podes generar automáticamente) y donde:
numero =  numero correlativo de visitas de un dia
tipo = tipo de hora, normal, extra etc.
entrada = hora de entrada
salida = hora de salida

Nota: Con este método podrías agregar mas campos como: notas, dirección, estado, lo que necesites apuntar de una visita.

Saludos.
    ¡Gracias!
#9

Buenas a todos, una vez leído lo que quieres implementar te hago mi sugerencia:
Lo primero, que no lo más sencillo, pero si lo correcto es la normalización de tablas en DB con regularidad se suelen hacer hasta la 3FN, casi nunca se llega a la 4FN o más. (dejo un enlace por si a alguien le puede interesar)
https://guru99.es/database-normalization/
Dicho esto, se que puede sonar a "si es una aplicación pequeñita para mi, no necesito esto".
Esto que os comento y relaciono aquí es la forma correcta a nivel empresarial de trabajar, si se coge como patrón de trabajo habitual, primero facilita enormemente la escalabilidad, que para un proyectito pequeño puede ser añadir un campito más, pero para proyectos de gran embergadura puede ser vital. Yo solo lo expongo como patrón de metodología luego ya, cada uno es cada cual.
Yendo al meollo del asunto y según mi visión para lo que tu quieres implementar, y solo basandome en lo que has indicado yo haría 3 tablas:
Primera tabla:
PARTES
ID (PK) Fecha Detalle (opcionalmente la columna de tipo de trabajo que sería FK de otra tabla a discutir)

Segunda tabla
PARTES-VISITAS
ID Parte_ID (FK) Visita_ID (FK)

Tercera Tabla
VISITAS
ID (PK) Descripcion

El nombre es totalmente orientativo y la verdad no se si fuese correcto.
(PK - Primary key)
(FK - Foreing key)
En el momento de poder trabajar con la recuperación CRUD de los datos solo tendrías que hacer el típico INNER JOIN para la unión de tablas la inserción sería de la misma forma, en las tres tablas.
Vale, una vez soltado todo el rollo, si por cualquier motivo ves que algo no te cuadra, me pasas los requerimientos del desarrollo y la parte de DB me ofrezco a realizarla yo mismo, te paso el script y luego tú ya lo desarrollas a nivel de Front y Back.
Saludos.
    ¡Gracias!
#10

Hola.

Ante todo muchas gracias a todos.

Calcena, tu enlace me ha parecido muy interesante y lo estoy estudiando a fondo para adaptar mi base de datos. Al ser un proyecto personal que nunca saldrá de mi ordenador (no lo voy a compartir con mis compañeros), no voy a pedirte que pierdas tu tiempo en diseñar una base de datos, aunque se agradece mucho tu gesto. Si fuese un proyecto que tuviera pensado compartir, entonces no lo dudaría, pero en este caso casi es mejor no molestarte. Lo dicho, estudio a fondo tu enlace y lo adapto a mis necesidades.

Un saludo.
    ¡Gracias!


Posibles temas similares…
Tema / Autor Respuestas Vistas Último mensaje

Salto de foro:


Usuarios navegando en este tema: 1 invitado(s)