Que base de datos usar?

[Neftali [Germán.Estévez]]

Si es para trabajar en local y sólo para almacenar datos de esa aplicación, yo te recomentaría una Base de datos de escritorio, que no requiera instalación, servidor,...
Posiblemente lo que yo haría sería ADO+MDB o XML.

NOTA: No comentas nada del volumen de datos tratar, cosa muy importante para decidir.

[alquimista]

El volumen en un principio no debe ser muy grande. Lo previsto seria como mucho una captura de un dia entero cada 5, 10,15 segundos.
Lo que daria unos 17000 registros + o -.
¿Es muy poco? Por eso decia lo de no usar BD.
Neftali... La aplicación es local no necesito server

[Faust]

Voto por Firebird, que incluso se puede hacer embeded,,,

[Neftali [Germán.Estévez]]

Si capturas un dato cada 5 segundos, tal y como tú dices, al día generarás unos 17.000 registros, por hablar de números exactos. No es un volumen muy grande y hacer una inserción cada 5 sg. no debería ser costoso. Hasta aquí bien, pero... (siempre hy un pero )

El problema es, ¿Qué vas a hacer después con esos 17000 registros diarios?

En un par de meses hablamos de 1 millón de registros. Y eso ya no es tan poco.

¿Me estoy perdiendo algo?

[alquimista]

La idea no es mantener en la misma BD todos los dias sino cada vez crear una base de datos nueva de captura como mucho de un dia de duracion y poder guardarla por si queremos analizar otro dia los datos. Lo de un dia es por poner mucho tiempo de captura. Vamos que no es fijo el valor y la pretensión es que si interesa guardas los datos y si no no los guardas. Es un poco captura de datos a petición del usuario.
No se si queda claro.??

PD: Se me olvidaba , luego lo interesante seria exportar datos a excel.

[[Delphius]]

Deberías analizar adecuadamente el uso que se le va a dar a esos datos.
Si la idea es luego armar una serie de estadísticas, reportes, etc. o cualquier operación es altísimamente probable de que requieres de consultas anidadas, cruzamiento de datos, etc.

Este motivo es más que suficiente como poner en la mesa el debate de si realmente conviene crear diferentes base de datos, ya sea una al día o a la semana o al mes, o año.

Si los datos están esparcidos por diferentes DBs, va a ser mas lioso el asunto.
Es mejor tener una BD y tirar contra ella.

Firebird cumple muy bien su tarea... si la preocupación es si aguantará una cantidad enorme de registros la respuesta es si.... el límite teórico que se ha calculado para una base de datos está en el orden del 1,5TB ¡Anda a llenar eso!

Tienes para años

Este hilo me hizo recordar a este otro. Sugiero su leída, se han dicho cosas interesantes en él.

Saludos,

[Neftali [Germán.Estévez]]

Empezado por alquimista

La idea no es mantener en la misma BD todos los dias sino cada vez crear una base de datos nueva de captura como mucho de un dia de duracion y poder guardarla por si queremos analizar otro dia los datos. Lo de un dia es por poner mucho tiempo de captura. Vamos que no es fijo el valor y la pretensión es que si interesa guardas los datos y si no no los guardas. Es un poco captura de datos a petición del usuario.
No se si queda claro.??

PD: Se me olvidaba , luego lo interesante seria exportar datos a excel.

Coincido con [Delphius] en que guardar una Base de Datos diaria es, a priori, un mal diseño, puesto que limita mucho las operaciones que luego vas a realizar. Piénsalo mucho y ten en cuenta las futuras posibilidades porque es una decisión muy importante.

Si de aquí a un tiempo a alguien se le ocurre que se deben hacer cosas como:
* Coger los datos de 2 días o de una semana , en lugar de 1 día.
* Comparar los datos de 2 días consecutivos.
* Totalizar datos de un mes/año.
* ...

P.D: que conste que yo mismo he sufrido en mis propias carnes lo de que tu jefe te dice: "Esto no va a pasar NUNCA, esto no se va a necesitar". En este punto puedes estar 98% seguro de que ese día llegará y eso se va a necesitar. ¿Adivina quien se va a "comer" el marrón?

Si aun así decides crear una Base de Datos diaria, MDB+ADO puede ser una buena solución. Incluso un XML.

Si por el contrario decides volcar todo en una Base de datos, con ese volumen, yo optaría por un SGBD. FireBird embebded o MySQL pueden ser buenas opciones.

[alquimista]

los datos son sencillos.

1 tabla y registros de pocos campos. nada de enlaces ni cosas complejas. y sacar valores maximos minimos, medios y poco mas. En realidad es consultaros si merece la pena usar BD.

[[Delphius]]

Empezado por alquimista

los datos son sencillos.

1 tabla y registros de pocos campos. nada de enlaces ni cosas complejas. y sacar valores maximos minimos, medios y poco mas. En realidad es consultaros si merece la pena usar BD.

Como consejo, nunca subestimes la sencillez.
Pepara el camino para lo nuevo. No hay que asumir las cosas son sencillas, que bastará con dos o tres cosas.

Un sistema está vivo, ahora puede que no, pero luego viene el marrón como dice Neftali. Las cosas cambian, se agregan, se modifican.
A mi lo que me "asusta" de tu comentario es "(...)y poco más(...)". El poco más puede que no se tan poco que imaginas.

No digo que tengas una visión pesimista pero si un poco de cuidado. De alerta.

Es mejor que prepares y hagas el sistema para trabajar con DB, sea Firebird o cualquier otro motor serio. Además esto no sólo ofrecen algunas funciones estadísticas ya incorporadas sino que además ofrecen estabilidad, perfomance, seguridad.

Esto también tiene y debe ser analizado. Y tal parece que no lo estás considerando.

Saludos,

[Neftali [Germán.Estévez]]

Empezado por alquimista

los datos son sencillos.

1 tabla y registros de pocos campos. nada de enlaces ni cosas complejas. y sacar valores maximos minimos, medios y poco mas. En realidad es consultaros si merece la pena usar BD.

En ese caso y si estás seguro, pues opta por un MDB. El acceso con ADO es sencillo y rápido.

Para las consultas posteriores puedes utilizar SQL.