Aquí gana Paradox frente al Firebird

[[newtron]]

Independientemente de lo que comentáis yo particularmente creo (y tengo comprobado) que las tablas de escritorio (Foxpro, DBase...), cuando no tienen decenas de miles de registros, son bastante más rápidas que las bases de datos cliente/servidor (Firebird, SQL Server...).

Otra cosa es si hablamos de estabilidad, robustez, funciones añadidas, etc.

Saludos

[[RONPABLO]]

Empezado por newtron

Independientemente de lo que comentáis yo particularmente creo (y tengo comprobado) que las tablas de escritorio (Foxpro, DBase...), cuando no tienen decenas de miles de registros, son bastante más rápidas que las bases de datos cliente/servidor (Firebird, SQL Server...).

Otra cosa es si hablamos de estabilidad, robustez, funciones añadidas, etc.

Saludos

Yo también lo noté, yo tenía mi base de datos en Paradox y funcionaba muy rápido, el problema era que esta rapidez se perdía al ir creciendo la base de datos, mientras Firebird (o MySQL en ese momento) seguía funcionando como cuando apenas tenía cientos de registros. Además que en un mes con unos 30 o 40 clientes con mi aplicación me tocaba que arreglar una o dos corrupciones de tablas

[[gatosoft]]

yo respecto bastante a Paradox, pues lo vi funcionar "muy bien" y por muchos años, a pesar de ser un proyecto abandonado a su suerte por borland hace miles de años.

Siin embargo los problemas asociados a su mantenimiento y estabilidad no compensan cualquier "punto positivo de performance" que podamos verle.

cuando digo que funciona "muy bien" y tiene "buen performance" lo hago desde un punto de vista relativo, pues creo que en general podría compararlo solo con sus hermanos (qeue prefiero no mencionar)

Sin haber trabajado realmente en Firebird, creo que estas juzgando demasiado rápido su potencial y desempeño. Y como muchos aqui creo que hay algo que no está bien ajustado en tu modelo de conexión o de trabajo.

Como sugiere Neftalí... ¿Y si el problema es el ClientDataset?. Recuerda que éste componente trabaja datos en memoria y además siempre guarda un Delta, es decir una copia de los datos. no obstante la mayoria d eproblemas asociados a éste componente están tambien relacionados con la costumbre heredada de programadores paradox de utilizar como caballito de batalla el componente TTable para todo. que desde mi punto de vista debería ser un componente prohibido.

Bueno, no queria sonar agresivo, (ya que ahora que leo de nuevo me lo parece), solo es un comentario de amigo.

[bulc]

que es mucho más ambicioso. Lo que pasa es que los aficionados tenemos la manía de pasar registros como si fueran cromos y claro ese no es el tema.
Mejor seleccionar que acumular. Debido a este defecto saturamos el ClientDataSet de tal manera que llega a agotar toda su capacidad de cargar registros.
Es lo que me ha enseñado la práctica. He aprendido a ir sacando los registros por letra inicial, por años, por número pero siempre con un número limitado.
De esta manera evito que me salga el "Error catastrófico" y el rendimiento es muy satisfactorio. Tan sólo se ralentizan los Insert como resultado de muchos registros. Eso es todo, en cuanto a inconvenientes. Todo lo demás (búsquedas, etc) van muy bien.
Y reconozco que el Paradox está ya fuera de onda. Aparte que la instalación del BDE se las trae para algunos sistemas.
Cada vez me encuentro más cómodo con Firebird, la verdad. Así que lo dejo así. Gracias por tu opinión y el tono tan respetuoso de tus notas.
Saludos,
bulc

[[fjcg02]]

Hola,
si además como indica Neftalí utilizas la versión embebida de Firebird, con creo que 8 ficheros necesarios para su buen funcionamiento, puedes distribuir tu aplicación de una forma muy sencilla.

Un saludo