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.
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.
Última modificación: 11-12-2020, 20:46 por jguardon.
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:
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
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:
Código:
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]
]
]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 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.
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.
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
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'
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.
¿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.
1 Saludo.
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
. Pensé que la base de datos era la forma mas sencilla.
Un saludo.
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
. Pensé que la base de datos era la forma mas sencilla.Un saludo.
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.
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.
1 Saludo.
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.
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.
Última modificación: 11-12-2020, 12:23 por calcena.
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.
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.