Que base de datos usar?
 

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

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.

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 :)

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

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.

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

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

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?

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.

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,

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? :D:D:D:D:D

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.

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,

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.

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

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.

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

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.:cool:

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.

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

Creo Access esta fuera de toda discusión, ni caso tiene perder el tiempo en eso pues como ya dijeron solo le servirá para windows. Yo insisto en recomendarme MySQL por que es bastante simple comenzar a trabajar con él y les pongo un pequeño ejemplo: EN FB no existen los campos autoincrementados, hay que hacer un trigger y un poquito de programacion adicional. En MySQL con solo decirle que tal campo es autoinc ya el solito se encarga. Ojo, no digo que sea mejor o peor, pero para alguien que NO necesita meterse en detalles de las BD sino que solo requiere el soporte para su aplicación creo que es más sencillo. Como ya platiqué anteriormente nuestro amigo no requiere conocer completamente los detalles de ambos motores, únicamente necesita un servidor a donde guardar sus lecturas y luego poderlas recuperar. O sea, no necesita meterse con triggers y cosas un poco más avanzadas.

jeje... bueno, y mysql no tiene la opción de mirror de firebird, así que mejor usar firebird ;)

Ya en serio, son detalles menores casi sin importancia, pero desde luego que es más práctico, seguro y "rentable" con el tiempo el usar mysql, postgresql, firebird, etc. que no usar una BD doméstica de access.

Además con mdb sí tienes que pagar licencia, ¡¡¡la licencia de windows!!!, sin embargo con las otras puedes usar linux :)

En mi opinión, tanta prevención puede resultar excesiva. No veo porqué desechar Access como no sea por una aversión particular. Pero si se trata de algo muy sencillo, ¿qué caso tiene plantearse hipotéticos e improbables escenarios futuros? Si la aplicación deja de ser sencilla entonces será tiempo de plantear algo más robusto. Mientras tanto con access es suficiente.

¿Cuál es esta opción?

// Saludos

Quería decir la opción "shadow", que crea una base de datos (o las que quieras) copias de la principal. Y se mantienen al mismo tiempo que la principal.
Aquí tengo un documento por si quieres echarle un vistazo.

Y, ¿por qué dices que MySQL no tiene esa opción?

// Saludos

Mi inglés es pésimo, pero me ha parecido entender que necesita alguna utilidad externa, ¿es así?.

De todas formas la opción "shadow" de firebird no es exactamente lo que se conoce como una replicación "normal", es una "replicación" en tiempo real y tan fácil de implementar que basta ejecutar una sentencia sql del estilo: create shadow labasedatos.shd, eso es todo, aunque admite diversos parámetros.

Eso me interesa Casimiro, en MySQL hay opción de crear servidores esclavos pero desgraciadamente la replicación es unidireccional. He estado buscando la forma de montar un servidor de BD (de cualquier sabor) que tenga redundancia real, es decir, se cae uno y el otro queda en automático montado como principal. Oye lo de shadow donde te guarda la copia? En el mismo servidor? En otro?

Bien, pero el shadow de firebird no es una replicación que funcione automáticamente si cae un servidor, tendrías que activarlo manualmente.
En windows es necesario y obligatorio crearlo en una unidad local, sin embargo en linux se puede ubicar en cualquier unidad "montada", por lo que puede ser externa.
Aquí tienes un documento que escribí hace tiempo para montar un shadow en un disco externo de red, en linux.
Para hacer lo que propones necesitas ayudarte de una utilidad como Heartbeat, tienes dos servidores replicados que esta utilidad va comprobando y en caso de caída de uno de ellos, pone en funcionamiento el otro servidor, totalmente "transparente" para el usuario, no se entera que se ha cambiado de servidor.
En mi trabajo tenemos algunos clientes con sistemas de ese tipo, en las últimas versiones de linux viene integrado en el kernel (creo que el propio heartbeat) por lo que es más fácil, cómodo y rápido de implementar.
Aquí tienes un documento de cómo montar un sistema de alta disponibilidad en linux con heartbeat.

Excelente Casimiro, aunque ya desviamos un poco el hilo pero creo que quien lo siga desde el principió verá que se fue desarrollando el tema a mi juicio bien. Gracias por los aportes simplemente excelentes

Al igual que Román, yo tampoco estoy de acuerdo con esa afirmación. :(:(

Estamos hablando de un programa Delphi (que funciona en Windows) que se debe conectar a un Base de Datos (local).
Jet4 (que no ACCESSS) para segun qué cosas es un buen motor de Base de Datos (siempre que se use para lo que está diseñado y de forma adecuada).

Si está descartado porque sólo funciona bajo Windows, por esa misma razón deberíamos descartar Delphi, pues sólo funciona bajo Windows.

Soy de los que piensa que todo DEPENDE. Y NO siempre MySQL/FB/SQLServer (por decir alguno) son mejores que Jet4/Parados/DBase (por decir algunos). Todo depende de para qué se vayan a usar.

vamos a ver jóvenes, que tengo la misma duda que se trata en este hilo.

Un sistema local para un solo usuario, con alguno que otro dato que capturar. Mas que nada leer información y sacar uno que otro reporte. Vamos, algo sencillo y rápido.

Si me decido a usar Firebird, ¿qué tengo que instalar en la máquina del usuario?, ¿tengo que configurar algo?

Con mdb, si mi memoria no me falla, copio el ejecutable, con el archivo mdb y listo; ¿con FireBird (o MySQL) es igual de sencillo?


saludos.

Con firebird, ejecutas el instalador y siguiente, siguiente, siguiente... se acabó.
No hay que configurar nada.
Y si usas la versión "embebida" sólo es copiar unos ficheros que pueden ir con tu programa.

instale la versión embedded de firebird en mi equipo, ejecuté y me aparece una consola de commandos, pero como no conozco nada, no supe que hacer...

¿que tengo que buscar para empezar a aprender?

Yo estaba esperando algo donde pueda crear bases de datos, dar clicks para crear tablas, click con el botón derecho y editar la tabla o algo así.... como access...

No he usado mucho FB Embebded, pero supngo que la herramienta de Administración/creación y demás no viene incluída. Para esto supongo que puedes bajar alguna externa; Yo la mejor que conozco de largo es IBExpert, que cuenta on una versión "free" para uso personal (y que puedes encontrar en el FTP del Club).

Por favor, si no es así, que alguien me corrija.

Con esta herramienta ya sí podrás crear las tablas como tú estás pensando.

Haz caso a Neftalí :)

El firebird "embedded" son sólo unos ficheritos que debes poner junto a tu programa. No sé qué consola de comandos te ha podido salir :)

firebird ISQL Tool:


y ahí me perdí... voy a intentar IBExpert....

Contra:
Firebird embedded es algo asi como el motor de base de datos. Tu como desarrollador deberas de instalar la version completa de FB, ahi desde alguna herramienta (IBExpert, FlameRobin) crear y manipular tus tablas. Al terminar tu aplicacion deberas distribuir con tu programa la fbclient.dll que permitira a tu programa en la maquina del cliente accesar la bd.


EDITO:

Solo para este Link la pagina no tiene desperdicio

Ese es el isql, sí, pero puedes usar ibexpert, marathon, flamerobin, etc. que son visuales.

se puede pensar en postgres
 

Hola a todos:

Mi sugerencia es la siguiente:

Teniendo en cuenta el número de registros y el posible crecimiento que ha tener la base de datos me permito meter en la lista de candidatos a POSTGRES, lo hago por varios aspectos:

El primero porque la puedes instalar en un equipo de escritorio o un un servidor como tal.

El segundo por que la puedes conectar utilizando los componentes Zeos, que resultan muy sencillos de manejar.

El tercero porque puedes implementar en el motor de la DB procedimientos almacenados o disparadores que te guarden en otro tabla registros que no cumplan con condiciones, es decir si algo es fuera de lo normal el mismo motor se encarga de evaluar y guardar, eso implica que la parte de evaluar datos la puedes montar el motor y no como código en tu aplicativo.

Cuarto por que cuando te des cuenta que requieres un servidor y lo montes (POSTGRES en la nueva máquina) tan solo debes cambiar en la pantalla de conexion (que se crea en la aplicación) el nombre del servidor y listo.

Quinto porque los datos son enviados de forma encriptada evitando que sean manipulados en su recorrido.

y sexto por si el del caso lo puedes pasar tu datos a otro motor como ORACLE (lease al reves) y en tu aplicación tan solo debes cambiar el protocolo (esto cuando se usan los componentes ZEOS).



gertorresm
Colombia

Sería necesario aclarar que postgres es una empresa que vende PostgreSql, que al ser software libre pueden disponer como quieran del programa.
Así que el original, libre y gratis lo encontrarás en la web de www.postgresql.org