Necesito de ustedes paraun concejo

[marto]

Wop!

Empezado por CFPA86

Es apto este motor de BD para tantos registros que esta BD va a tener (mas de 1.500.000 reg.)?,

Yo lo máximo que he visto (y veo, porque la aplicación aún se usa) en tablas paradox son 200.000 registros. Pese a que no usamos ni integridad referencial ni indices secundarios para conseguir tener los mínimos archivos "corrompibles", el rendimiento es lamentable y los costes de mantenimiento altísimos (principalmente por que cascan los indices )

[DarkByte]

Como pides un consejo, te lo doy, Leete la guía de estilo y mira en qué has fallado

[Mick]

Empezado por marto

Wop!
Yo lo máximo que he visto (y veo, porque la aplicación aún se usa) en tablas paradox son 200.000 registros. Pese a que no usamos ni integridad referencial ni indices secundarios para conseguir tener los mínimos archivos "corrompibles", el rendimiento es lamentable y los costes de mantenimiento altísimos (principalmente por que cascan los indices )

Si no tienes indices definidos es normal que el rendimiento sea lamentable, uses las tablas que uses.
Es mas, los sistemas navegacionales son mas rapidos realizando determinadas tareas que los sistemas cliente/servidor.
Paradox es perfectamente usable si el numero de puestos no es muy grande, como lo demuestran miles de aplicaciones que existen en el mercado.
En tu caso particular tienes que tener problemas de diseño, uno de ellos es el no uso de indices, cosa necesaria en cualquier sistema de base de datos sea paradox, o interbase o el que sea.
Otro problema que puedes tener, es que la red en la que se este implementado el sistema no funcione correctamete: de forma demasiado lenta y perdiendo paquetes (esto es una razon que puede provocar que los archivos se estropeen: sean indices de paradox o cualquier otro archivo que se este escribiendo a traves de la red) esto es muy comun, hay montones de pequeñas empresas por ahi con sistemas y cableados que no funcionan del todo bien: es muy facil que un switch no funcione correctamente, o un driver de alguna tarjeta de red tenga bugs y haya que actualizarlo o mas facil incluso que los cables de red no esten bien hechos (te sorprenderias de la cantidad de tecnicos de redes que no saben hacer correctamente los cables).
En definitiva, si el numero de puestos va a ser pequeño, es preferible utilizar un sistema de tablas planas (estilo paradox), ya que es mas facil de instalar y tiene en general menos mantenimiento que un sistema cliente servidor.
Si el numero de puestos va a ser grande es preferible usar un sistema cliente/servidor.

Saludos

PD: Segun mi experiencia (basada en miles de instalaciones actualmente funcionando), si en un sistema implementado con tablas paradox se estropean continuamente los indices, es que existe un problema de hardware: la red o algun ordenador no funciona correctamente.

[marto]

Empezado por Mick

Si no tienes indices definidos es normal que el rendimiento sea lamentable,

Eso depende del tipo de aplicación. Esta en concreto, a excepción de los informes, que no es bastante igual lo rápido que chuten, se trata de pantallas de inserción. A más índices, más lento.

Empezado por Mick

Paradox es perfectamente usable si el numero de puestos no es muy grande, como lo demuestran miles de aplicaciones que existen en el mercado.

La propia Borland no recomienda su uso en tablas de más de 15000 registros

Empezado por Mick

Otro problema que puedes tener, es que la red en la que se este implementado el sistema no funcione correctamete: de forma demasiado lenta y perdiendo paquetes

La aplicación se "rompe" hasta en instalaciones sin red.... una caida de luz o un ordenador mal apagado y tabla corrupta al canto

Empezado por Mick

En definitiva, si el numero de puestos va a ser pequeño, es preferible utilizar un sistema de tablas planas (estilo paradox), ya que es mas facil de instalar y tiene en general menos mantenimiento que un sistema cliente servidor.

Empezado por Mick

PD: Segun mi experiencia (basada en miles de instalaciones actualmente funcionando) ...

Sin quere ofender, no sé cuál será tu experiencia, pero decir que Paradox da menos trabajo o es más rápido que, por ejemplo IB/Firebird, es de juzgado de guardia

[jachguate]

Creo que paradox fácilmente puede ser mas rápido que interbase firebird. También btrieve lo es (y estoy seguro que mas que paradox).

En el caso concreto de paradox, depende, como ha dicho mick, que tengas un número reducido de usuarios. Con un sistema de 4 o mas usuarios, creo que comenzarías a tener problemas por la saturación de la red (que depende también de como esten programados los clientes) y quizas, los bloqueos.

Con btrieve, he visto sistemas con 50 o 60 usuarios trabajar sin problemas, y sin corromperse jamás un índice.

Pero eso fué hace bastantes años... y por ahora, creo que, de cara al futuro, es mejor comenzar con una bd cliente servidor de una vez. Dependerá de los objetivos de tu sistema también, que para almacenar recetas de cocina, incluso access estaría bien.

Pero 1,500,000 registros, y contando... yo me iria por una BD mas robusta y escalable.

Hasta luego.

[marto]

Empezado por jachguate

Creo que paradox fácilmente puede ser mas rápido que interbase firebird

¿Con tablas de ese tamaño? tú pon 1.000.000 en una tabla paradox con todos los índices que quieras y la abres.... y luego me cuentas. Si estamos en monopuesto, quizá los resultados podrían llegar a ser parecidos, pero en red, solamente teniendo en cuenta que paradox te obliga a traerte a local todos los registros.... amigo eso es muy lento.
Y en el tema de mantenimiento prefiero ni entrar

[Mick]

Efectivamente una caida de un equipo incluso en monopuesto, puede corromper las tablas o indices, exactamente de la misma forma que si el servidor se cae en firebird/interbase/etc tambien se pueden corromper las tablas.
La diferencia y ventaja de un sistema cliente servidor, es que solo el mal funcionamiento del servidor puede corromper las tablas, ya que es el unico que accede directamente a la base de datos.
En un sistema de tablas planas como todos los equipos acceden directamente a los datos el mal funcionamiento de cualquiera de los equipos puede estropear los datos.
Por eso con pocos equipos no tiene mayor problema ya que el riesgo de mal funcionamiento de unos pocos equipos es pequeño. Otra cosa es que tengamos decenas o cientos de clientes, en ese caso es facil que algun equipo siempre este funcionando mal o averiado, con lo que el mantenimiento se vuelve imposible.

Pero en general eso es la unica diferencia fundamental, un sistema cliente servidor no hace milagros para que las tablas no se estropeen, gestiona igualmente registros e indices como cualquier sistema de tablas planas, la diferencia es que solo un equipo (el servidor) hace las inserciones/modificaciones/borrados.

Puedes buscar en google por corrupcion de datos veras que en todos los sistemas de base de datos existe ese problema.

En general un sistema monopuesto de tablas planas tiene las mismas posibilidades de que se estropeen las tablas que un sistema cliente servidor con un solo cliente.

Contrariamente a los que dices, precisamente las inserciones y modificaciones no tienen mayor problema en cualquier sistema de base de datos, salvo procesos especificos, el alta de datos es realizado por operadores que tienen que teclear la informacion de modo que el tiempo en que se tarda en insertar un registro (aunque tenga muchos indicees) es irrisiorio (unos milisegundos) aunque sea a traves de la red. Si en tus sistemas eso se vuelve lento, repito, tu red no funciona bien: normalmente una tarjeta de red media (de 100Mb puede transmitir datos a 5 o 6 Megabytes/segundo) eso es velocidad totalmente sobrada, para hacer cientos o miles de inserciones por segundo.

Normalmente el punto fuerte de los programadores en general no es el hardware sino simplemente programar, he visto muchos casos de programadores volviendose locos buscando bugs en sus programas, cuando precisamente el software estaba correctamente y el problema era averias de hardware o bugs en drivers del sistema operativo. Nadie puede exigir que un software funcione si el hardware en el que se debe ejecutar no funciona bien o no esta correctamente montado. Cosas como la necesidad de un SAI es basica, cualquier sistema de base de datos se puede corromper si se va la corriente, y hay muchos programadores que cosas como esta no lo saben o no los tienen en cuenta.

Ningun sistema es la panacea, hay determinadas procesos que se pueden hacer mas rapido usando tablas planas, y otros que se realizan mas rapido en sistemas cliente/servidor. Es de sobra sabido por todos que la forma de trabajar y programar en cliente/servidor es distinta que con tablas planas porque hay cosas que precisamente no se pueden hacer sin perder rendimiento en sistemas cliente/servidor por el hecho de no poder acceder directamente a los registros.

La cuestion esta en usar la herramienta mas adecuada para cada proyecto o situacion , no se puede decir que un sistema de bases de datos determinado (sea paradox, o interbase o el que sea) es el mejor para todos los casos.

Otra cosa muy importante es saber los requerimientos, carencias, puntos fuertes, y configuraciones necesarias de cada sistema antes de empezar a utilizarlo.
Por ejemplo es bien sabido que interbase debe estar en modo sincrono si se quierea minimizar la posible corrupcion de datos en los servidores (a costa eso si de perder velocidad). Igualmente un servidor de datos que almacene tablas planas se puede configurar de este modo para que se grabe inmediatamente la informacion al disco duro.
Me pregunto cuantos de los que estan leyendo esto y usan o han usado tablas planas, han configurado los servidores para que la informacion se grabe inmediatamente (y no me refiero al uso de flushbuffers o cosas por el estilo en el programa).
Me pregunto tambien cuanta gente antes de hacer una instalacion en un cliente , comprueban la velocidad de la red asi como el cableado y la distribucion de colores de los conectores de red para asegurarse de que han sido montados correctamente (esto suele estar mal en un tercio de las instalaciones).

Saludos
Miguel

[marto]

Wop!

Empezado por Mick

La diferencia y ventaja de un sistema cliente servidor, es que solo el mal funcionamiento del servidor puede corromper las tablas...

¿Y te parece poco?

Empezado por Mick

Por eso con pocos equipos no tiene mayor problema ya que el riesgo de mal funcionamiento de unos pocos equipos es pequeño.

Bueno... eso es bastante subjetivo, pero sigo sin ver qué te aporta Paradox que no aporte un C/S, sigues corriendo más riesgos con Paradox

Empezado por Mick

Pero en general eso es la unica diferencia fundamental,

Bueno sí, eso y que solamente llegan al cliente los registros necesarios, y que tienes integridad referencial como dios manda, y procedimientos en el lado del servidor, y triggers y...

Empezado por Mick

Puedes buscar en google por corrupcion de datos veras que en todos los sistemas de base de datos existe ese problema.

Eso nadie lo discute

Empezado por Mick

En general un sistema monopuesto de tablas planas tiene las mismas posibilidades de que se estropeen las tablas que un sistema cliente servidor con un solo cliente.

Las mismas, las mismas... llevo 3 años con Oracle y aun no he visto una tabla corrupta, no digo que no pase, pero de ahí a que pase tanto como en Paradox en monousuario....

Empezado por Mick

Contrariamente a los que dices, precisamente las inserciones y modificaciones no tienen mayor problema en cualquier sistema de base de datos,

Eso no es enteramente cierto. Es necesario bloquear registros, con lo cual hay que acceder al fichero de bloqueos. De todas maneras, por eso decía que trabajamos sin índices (a excepción de las PK, claro)

Empezado por Mick

milisegundos) aunque sea a traves de la red. Si en tus sistemas eso se vuelve lento, repito, tu red no funciona bien

Lo que funciona mal no es la escritura, eso es rápido. El problema es que antes tienes que leer los datos y, claro, estamos en lo mismo, cuando trabajas con tablas grandes y te las has de bajar enteras....

Empezado por Mick

Normalmente el punto fuerte de los programadores en general no es el hardware sino simplemente programa...

En eso tienes razón, de hecho, los que trabajamos en empresas medianamente grandes, contamos con compañeros de sistemas que se supone que se encargan de que todo lo que comentas está bien. Que yo me ponga a repasar cómo grimpan es como si ellos repasasen mi SQL

Empezado por Mick

Ningun sistema es la panacea, hay determinadas procesos que se pueden hacer mas rapido usando tablas planas, y otros que se realizan mas rapido en sistemas cliente/servidor.

Pues alguno abrá, pero ahora no se me ocurre ninguno que justifique usar Pradox o Access, a no ser la ignorancia del programador, claro :P

[jachguate]

Empezado por Mick

Efectivamente una caida de un equipo incluso en monopuesto, puede corromper las tablas o indices, exactamente de la misma forma que si el servidor se cae en firebird/interbase/etc tambien se pueden corromper las tablas.

Una diferencia importante, y creo que vale la pena aclararla, es que hay menos posibilidades que ante una caida (digamos por falta de corriente) se corrompan las tablas de un servidor oracle o firebird, que la que habría ante la misma caida de un monopuesto con paradox. De esto, también google creo que puede dar buenas referencias, que alguna estadística debe haber por alli. A mi me lo dice el sentido común, puesto que estos servidores implementan métodos de recuperación de fallos. Firebird, por ejemplo, la mayoría de las veces, simplemente volvería a su último estado consistente antes del fallo eléctrico.

N discuto que hay casos en los que se corrompería inevitablemente, pero realmente estos mecanismos de recuperación ayudan mucho a evitarlo. No conozco a profundidad paradox, pero ¿tiene algo similar?

En el caso ya mencionado de Oracle... he dedicado buena parte de mis esfuerzos en lectura de los últimos meses a documentarme sobre los mecanismos de que dispone Oracle para recuperarse de fallos. Uf... es sorprendente la tecnología que han desarrollado en torno a esto. Es posible incluso de fallos físicos en los discos. Obviamente hay un procedimiento a seguir, y tiene un costo en hardware y software... pero existe para quien necesite estar protegido contra todo.

Empezado por Mick

La diferencia y ventaja de un sistema cliente servidor, es que solo el mal funcionamiento del servidor puede corromper las tablas, ya que es el unico que accede directamente a la base de datos.

Gran ventaja, ¿no?

Empezado por Mick

el riesgo de mal funcionamiento de unos pocos equipos es pequeño.

Eso depende de las características/edad de los componentes de hardware, del ambiente y de muchas otras cosas. He visto sistemas monopuesto, que yo catalogaría de alto riesgo..

Empezado por Mick

un sistema cliente servidor no hace milagros para que las tablas no se estropeen

Nadie ha dicho que haga milagros... pero ¿te he contado de oracle?

Empezado por Mick

gestiona igualmente registros e indices como cualquier sistema de tablas planas, la diferencia es que solo un equipo (el servidor) hace las inserciones/modificaciones/borrados.

Yo diría que si, pero que incluso en la gestión puede ser mucho mas óptimo. En tablas planas, el único caso excepcional que conozco, y que ya he mencionado antes, es btrieve.

Empezado por Mick

Puedes buscar en google por corrupcion de datos veras que en todos los sistemas de base de datos existe ese problema.

Un punto inevitable. Habrá que sacar un indicador que nos arroje luz sobre un "coeficiente de corrupción" que involucre variables tales como Número de corrupciones, Número de instalaciones, Número de usuarios concurrentes, etc.

Empezado por Mick

En general un sistema monopuesto de tablas planas tiene las mismas posibilidades de que se estropeen las tablas que un sistema cliente servidor con un solo cliente.

Este punto es MUY discutible, yo no lo creo.

Empezado por Mick

las inserciones y modificaciones no tienen mayor problema en cualquier sistema de base de datos

.
Depende del "tipo" de sistema de bases de datos. Conozco algunos donde hay miles de operadores grabando registros, donde esos "irrisorios" milisegundos se pueden convertir en un verdadero cuello de botella. También conozco sistemas de bases de datos que no dependen de un operador "humano", sino que están registrando información generada por otras máquinas, y que puede ir a ritmos verdaderamente vertiginosos. Por algo los señores de la computación se han inventado términos como OLTP, OLAP y similares.

Empezado por Mick

normalmente una tarjeta de red media (de 100Mb puede transmitir datos a 5 o 6 Megabytes/segundo) eso es velocidad totalmente sobrada, para hacer cientos o miles de inserciones por segundo.

Estas suponiendo, erroneamente creo, que el cuello de botella es la red. Habrán casos en que efectivamente lo es, y habrán otros en que la red tiene poco que ver.

Empezado por Mick

hay determinadas procesos que se pueden hacer mas rapido usando tablas planas, y otros que se realizan mas rapido en sistemas cliente/servidor.

En el caso específico de un usuario... con un sistema bien diseñado, creo que siempre irá mas rápido las tablas planas. El punto de discusión, según entiendo, no es solo la velocidad.

Empezado por Mick

hay cosas que precisamente no se pueden hacer sin perder rendimiento en sistemas cliente/servidor por el hecho de no poder acceder directamente a los registros.

Lo cual puede ser una gran ventaja... según de donde se vea. Desde el punto de vista de la seguridad, por ejemplo... es mucho mejor que no se pueda acceder directamente a los registros. Te ofrece una mayor garantía que solamente aquellos usuarios con las credenciales adecuadas podrán acceder a ellos, ya sea para verlos o para modificarlos.

Empezado por Mick

La cuestion esta en usar la herramienta mas adecuada para cada proyecto o situacion, no se puede decir que un sistema de bases de datos determinado (sea paradox, o interbase o el que sea) es el mejor para todos los casos.

En este punto estamos totalmente de acuerdo... aunque creo que es de sobra evidente que en la mayoría de los casos es preferible un sistema C/S. Incluso para pequeñas tiendas o negocios, de cara al futuro, es mejor contar desde el inicio con un sistema que les permita escalar de acuerdo a su crecimiento. En el caso de firebird, el costo es mínimo desde el inicio, por lo que no veo muchas ventajas en no elegirlo (en muchos casos).

Empezado por Mick

Otra cosa muy importante es saber los requerimientos, carencias, puntos fuertes, y configuraciones necesarias de cada sistema antes de empezar a utilizarlo.

Definitivo. Cualquier programador que no cumpla esto, es un verdadero irresponsable.

Hasta luego.