Necesito de ustedes paraun concejo

[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

[Mick]

Empezado por marto

Wop!
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

Claro que puedes correr un poco mas de riesgo, pero esa posibilidad es pequeña si el numero de puestos es pequeño. Es como si prefieres comprar un tanque en lugar de un coche porque ante un accidente vas a correr menos riesgos. El tanque sera muy seguro pero no siempre es lo mas adecuado en todas las situaciones.

Empezado por marto

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

Me gustaria saber "cuantos sistemas con oracle mantienes", mis razonamientos se basan en miles de sistemas actualmente funcionando con
paradox. No se pueden sacar conclusiones generales de 1 o 2 o 3 sistemas nada mas.

Empezado por marto

Wop!
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)

El acceso al fichero de bloqueos, es una escritura mas de unos pocos bytes en un archivo, esto es indiferente, los sistemas cliente/servidor tambien tienen que marcar los registros o paginas enteras como bloqueadas en algun lado, el sistema de interbase es un poco mas especial ya que es el unico sistema cliente servidor que utiliza una arquitectura multigeneracional, pero al final tiene igualmente que marcar o duplicar los registros ante una modificacion.

Empezado por marto

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

Eso es una barbaridad, para hacer una insercion no hay que bajarse enteras las tablas, precisamente esta es una de las ventajas de un sistema no cliente servidor, puedes acceder directamente de forma aleatoria a un registro (una zona del archivo) para modificarlo.
Otra cosa es que uno intente programar en sistemas de tablas planas como si fuese un sistema cliente servidor (utilizando querys para todo).
Donde precisamente si se producen cuellos de botella de ese tipo, es en aplicaciones hechas con sistemas clientes servidor por programadores que estan acostumbrados a utilizar tablas planas, y no saben que hay que cambiar la forma de programar y solicitar solo subconjuntos pequeños de datos al servidor.
Puedes consultar estos foros veras montones de ejemplos, de gente com problema de lentitud en interbase precisamente por que se empeñan en utilizar un grid para mostrar todos los registros de una tablas (select * from table), y se traen todos los datos hacia el cliente. O se empeñan en hacer locates sobre querys como si fuesen tablas, lo que precisamente exige el envio de todos los registros hacia el cliente.
Estos programadores estan acostumbrados a que la navegacion por los registros en grids sea rapida (ir al principio y al final,etc) , precisamente porque los sistemas de tablas planas solo leen de los archivos aquellos registros que necesitan, para leer los datos del final de una tabla en un sistema de tablas planas no es necesario traer los registros anteriores, o relanzar una nueva query que solo involucre a estos ultimos registros.

En definitiva la insercion y modificacion de datos es tan rapida como cualquier otro sistema. Lo que si es mas lento utilizando tablas planas es la creacion
de informes complejos que involucren todos los registros de las tablas, y esto siempre y cuando no se realizen estos calculos directamente desde el servidor. Pero normalmente la velocidad en el calculo de determinados informes no es critica, porque no es una operacion que se este haciendo continuamente sobre el sistema, lo que si se hace continuamente en la mayoria de los sistemas, son determinadas consultas (que definiendo los indices adecuados en las tablas son inmediatos), inserciones y modificaciones.

Saludos
Miguel

[marto]

Empezado por Mick

Claro que puedes correr un poco mas de riesgo, pero esa posibilidad es pequeña si el numero de puestos es pequeño. Es como si prefieres comprar un tanque en lugar de un coche porque ante un accidente vas a correr menos riesgos. El tanque sera muy seguro pero no siempre es lo mas adecuado en todas las situaciones.

Eso es demagogia, las ventajas de un coche sobre un tanque son evidentes, tú sigues sin dar ninguna para defender los sistemas de tablas planas.

Empezado por Mick

Me gustaria saber "cuantos sistemas con oracle mantienes", mis razonamientos se basan en miles de sistemas actualmente funcionando con
paradox.

Sin duda ese razonamiento es irrebatible.... es como cuando mi padre me decía que de mayor lo entendería. De todas maneras espero no tener que administrar nunca "miles de sistemas" en paradox

Empezado por Mick

Eso es una barbaridad, para hacer una insercion no hay que bajarse enteras las tablas, precisamente esta es una de las ventajas de un sistema no cliente servidor, puedes acceder directamente de forma aleatoria a un registro (una zona del archivo) para modificarlo.

Perdona mi ignorancia y que diga tantas barbaridades, podrías ilustrarme y explicarme cómo haces eso con un fichero que está en otra máquina? ¿Y como haces para hacer un Locate o un filtro?

Empezado por Mick

Donde precisamente si se producen cuellos de botella de ese tipo, es en aplicaciones hechas con sistemas clientes servidor por programadores que estan acostumbrados a utilizar tablas planas, y no saben que hay que cambiar la forma de programar y solicitar solo subconjuntos pequeños de datos al servidor.

Bueno, ya dije que la incompetencia del programador podía ser un buen motivo para quedarse con Paradox

Empezado por Mick

En definitiva la insercion y modificacion de datos es tan rapida como cualquier otro sistema. Lo que si es mas lento utilizando tablas planas es la creacion

Tendré que hablar con mi jefe y decirle que tire todos los IB y Oracle y que volvamos a Paradox.... cómo se me podían escapar tantas virtudes
Perdona por la ironía, pero es que ante tanto sinsentido me quedo sin argumentos... no sé por dónde empezar

[kinobi]

Hola,

Empezado por Mick

Me gustaria saber "cuantos sistemas con oracle mantienes", mis razonamientos se basan en miles de sistemas actualmente funcionando con
paradox. No se pueden sacar conclusiones generales de 1 o 2 o 3 sistemas nada mas.

Evidentemente, el argumento basado en tener miles de instalaciones funcionando (no dudo que estupendamente) en Paradox, no demuestra ninguna ventaja (o desventaja) sobre otras posibles alternativas, aunque puedan existir.

Otro asunto sería que tu argumentos se basaran en miles de instalaciones Paradox y miles de instalaciones pon_la_alternativa_que_quieras.

Empezado por Mick

El acceso al fichero de bloqueos, es una escritura mas de unos pocos bytes en un archivo, esto es indiferente, los sistemas cliente/servidor tambien tienen que marcar los registros o paginas enteras como bloqueadas en algun lado, el sistema de interbase es un poco mas especial ya que es el unico sistema cliente servidor que utiliza una arquitectura multigeneracional, pero al final tiene igualmente que marcar o duplicar los registros ante una modificacion.

El sistema multigeneracional de Firebird/InterBase no duplica realmente registros completos ante una modificación. El motor crea un delta de los campos tocados (y no de registros completos), y asocia este delta a la transacción implicada. Para seguir la pista a los cambios aplicados, el sistema mantiene una lista con los identificadores de las transacciones/deltas que han provocado los cambios.

Saludos.

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