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