Que base de datos usar?

[alquimista]

Hola muy buenas..

Me gustaria consultar a los foreros que base de datos usar para una aplicación que capture datos por serie y que almacene unos pocos campos.
ejemplo: Fecha hora de captura, valor sensor 1,...,valor sensor n (n<=10)
para luego ponerlos en una grafica en funcion del tiempo.

A lo mejor no merece la pena usar base de datos..

No se que me recomendais, que sea sencillo de implementar.
Gracias

[[AzidRain]]

Pues depende mucho de si esas lecturas las va a utilizar para algo en especial. Si solo es llevar un registro hasta con BDE lo puedes hacer pero si tienes pensado usarlas para hacer datamining o análisis estadístico te conviene mas un motor basado en SQL que puede ser ya sea MySQL o Firebird, yo te recomendaría MySQL por ser relativamente más sencillo de hechar a andar y mantener que Firebird y SQL Server. Aclaro, no digo que sea mejor, pero para tus necesidades creo que lo más te interesa es echar a andar algop rápido y sin mucha complicación, pues es claro que tu proyecto es enfocado a un entorno no muy administrativo.

[Casimiro Notevi]

De acuerdo con AzidRain menos en una cosa: ¿mysql es más fácil de echar a andar que firebird?, yo diría que firebird es lo más fácil de echar a andar, lo hago hasta yo mismo

[alquimista]

No esta todavia claro el uso de los datos (me falta un poco de info) pero me imagino que sera encontrar valores max, minimo y hacer la grafica de una captura de datos. Lo de la estadistica no lo se...
No estoy muy puesto en BD (solo he hecho algo muy pobre en ADO, access)
No conozco los demas motores...
He visto cosas como XML ¿eso es para BD?

Saludos

[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.

[alquimista]

Bueno...
Delphius quizas mis comentarios son debido a mi poco trabajo con BD...
La verdad que convertis la programación en una filosofía....
Tomare en cuenta las consideraciones de precaución... e intentare meditar vuestras sabias palabras...
Quizas opte por ADO+MDB como dice Neftalí ya que he hecho algo con ADO.
La verdad es que no habia pensado meter mas capturas en la BD. Pero es una opción mas que aceptable.

Gracias...

PD: Delphius gracias por el otro hilo, me parece muy interesante y creo que me va a servir bastante...

[[AzidRain]]

Todo apunta a que utilices ya sea FB o MySQL y que te olvides del concepto de bases de datos por día ya que al final te va a resultar mucho más útil poder hacer análisis de digamos un año de datos teniendo oportunidad de hacer todo tipo de estadísticas sin limitación. Si los registros son sencillos como mencionas es precisamente lo que hace más potente a cualquiera de las 2 opciones pues podrán trabajar a full sin importar si son 100 o 1 millon de registros.

Imagináte que tu cliente o tu jefe quiera saber...¿Cual es la hora en que en promedio la lectura de tal variable sobrepasa tal valor?, ¿Cual es el día de la semana en que x variable baja de y valor?..." y un largo etc.

La potencia del datamining o minería de datos estriba en tener la mayor cnatidad de datos disponibles cada vez.

[[newtron]]

Hola amigos.

En mi modesta opinión pienso que ya que te vas a poner en la faena de montar una base de datos, con casi el mismo trabajo te metes en firebird o mysql y te ahorras problemas en el futuro.

Saludos

[alquimista]

En vista a las opiniones que comentais voy a probar Firebird.
Si se usa ADO +mdb ¿es necesaria una licencia de Access?

Gracias por vuestras opiniones.. y sabiduria.

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

Empezado por alquimista

Si se usa ADO +mdb ¿es necesaria una licencia de Access?

Puedes usar desde Delphi una Base de Datos .MDB y el motor de Jet 4 para acceder sin ni siquiera tener Access. Sólo necesitas que el ordenador tengas instaladas las MDAC (a día de hoy está en todos los sistemas windows).

Hablando con propiedad sería: "Access no es más que un programa que utiliza El Motor de Datos Jet4, para trabajar con ficheros MDB."
A veces confuncimnos los términos.
Se puede utilizar el motor de Jet4 líbremente y no hay que pagar licencia por elllo. Que es lo que vas a hacer tú desde tu programa Delphi.
No es necesario tener instalado ni siquiera el Office, ya que hay varios programas que vía ADO te permiten crear un MDB, las tablas y los campos.

[[Caral]]

Hola
Escenario 1:
Access, ado:
1- windows
2- El sql usado no es convencional con otros motores.

Escenario 2:
Firebird, IB:
1- Windows, linux
2- Sql casi normal.

Con esto quiero decir que si algun dia se les ocurre usando access:
1- cambiar a linux.
2- cambiar de BD.
Pasara:
1- No podra,
2- Le costara, Ni Komca, ni Kexi para linux no caminan igual..
3- tendra que modificar el programa completo.

Tal vez no sea el caso, pero es bueno tenerlo en cuenta, tal vez en algun ordenador no se tenga windows y se requiera del programa.
Saludos