Necesito de ustedes paraun concejo

[CFPA86]

Hola foro, ya se que este hilo no se especializa en dar concejos, disculpemen, pero necesito de ustedes, resulta que realice una aplicacion en D3 usando paradox v.7.0, la aplicacion funciona bien pero mi primera pregunta es. Es apto este motor de BD para tantos registros que esta BD va a tener (mas de 1.500.000 reg.)?, ahora mi segunda duda, esta BD le interesan a varias personas que logicamente estan conectadas a Internet, D3 me permite programar tanto la conexion para visualizar la BD en las estaciones, ademas de alguna interfaz (Hoja) en internet para que se pueda manipular dicha BD?, si no es D3 cual otro lenjuage? espero haberme dado a entender y gracias por sus comentarios que meserviran de mucho para poder tomar una decision acertada.

Chaoooooooooooooooooooo

[jachguate]

Te recomiendo pasar de Paradox, y basarte en algo mas estable/robusto, como Interbase/Firebird, o mySQL.

No veo porque no hacer la paginilla en D3, siempre que tu webserver corra sobre windows, y tenga soporte para CGI/Isapi.

Luego hay soluciones mas estándarizadas, como PHP, que correrá en multiples plataformas y puede hacerlo como módulo de apache.

Saludos.
;)

[marto]

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

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]

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.


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


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


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.


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]

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!

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?


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


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


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


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


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)


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


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

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]

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.

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.

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.

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

[jachguate]

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.

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?

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

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?

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.

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.

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.

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.

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.

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.

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.

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

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.

;)

[marto]

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.


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




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?


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


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 :confused: :confused:
Perdona por la ironía, pero es que ante tanto sinsentido me quedo sin argumentos... no sé por dónde empezar

[kinobi]

Hola,

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.

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.

[Mick]

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?


Para ello estan los indices.

Un archivo de incide puede estar organizado en forma de un arbol ordenado de tipo b, b* o b+, etc. Hay distintas variaciones pero lo fundamental, es que el archivo se divide en distintos bloques, digamos de 4096 bytes cada, uno. Cada bloque es un nodo del arbol.

En cada nodo se guardan de forma ordenada los valores del campo o campos que formen el indice, por cada valor se guarda tambien una referencia (un puntero) al registro en la tabla principal.

Los hijos de cada nodo son otros nodos en los que se guardan los valores menores y mayores de los campos con respecto a sus padres.

Supongamos que tenemos un indice sobre un campo de tipo cadena, digamos campo 'nombre' de de 32 bytes.

Luego, en cada nodo padre caben 4096/(32+8)= sobre 100 campos proximadamente.

Cada nodo puede tener hasta 101 nodos hijos.

En un arbol organizado de esta forma y que tuviese 3 niveles, cabrian aproximadamente 101*101*101 ~ mas de 1 millon de campos.

Esto significia que si tenemos una tabla de 1 millon de registros y queremos localizar un registro que cumpla la condicion nombre='PEPE%', el ordenador cliente tendria que leer como MAXIMO 3 nodos en el archivo de indice para localizar el registro.

Eso serian leer 4096*3= 12288 bytes a traves de la red.

Considerando que con una tarjeta de red normalita puedes leer a 6.000.000 bytes por segundo, podemos concluir que el retraso ocasionado por la velocidad de la red en la busqueda en una tabla de 1 millon de registros es bastante aceptable, sobre 2 milisegundos para localizar el registro.

Saludos
Miguel

[Mick]

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


Hombre, si tienes miles de instalaciones con problemas 0, no es necesario compararlas con nada mas. Claro que en este caso 0 no es la realidad pero el numero de problemas es minimo y totalmente aceptable.


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.

Efectivamente, interbase trabaja a nivel de campo no de registro, para la proxima sere mas cuidadoso, pero la cuestion era intentar explicar que cualquier otro sistema necesita igualmente escribir en la base de datos y marcar los bloqueos (en el sentido amplio de la palabra) de alguna forma.

Saludos
Miguel

[kinobi]

Hombre, si tienes miles de instalaciones con problemas 0, no es necesario compararlas con nada mas. Claro que en este caso 0 no es la realidad pero el numero de problemas es minimo y totalmente aceptable.

Insisto, 0 problemas con un determinado sistema (y ahora estoy hablando genéricamente) en miles de instalaciones no lo convierten en un mejor sistema en relación a otros. Podría venir alguien y poner encima de la mesa miles de sistemas (pongamos el doble que tú, y también sin problemas) utilizando otro motor de datos y no por ello se convertiría en un mejor sistema.

Y entrando en relación al tema que se trata, basar las hipotéticas ventajas de un motor de datos sobre otro en función de determinados parámetros de rendimiento en casos concretos (a pesar de ser miles), es un argumento importante, pero no definitivo. Los servidores de datos relacionales pueden hacer muchas más cosas que las que se pueden hacer con un motor basado en archivos indizados, a pesar que en determinadas circunstancias estos últimos puedan tener un rendimiento (en cuanto a velocidad de acceso) superior a los primeros.

Saludos.

[Mick]

Y entrando en relación al tema que se trata, basar las hipotéticas ventajas de un motor de datos sobre otro en función de determinados parámetros de rendimiento en casos concretos (a pesar de ser miles), es un argumento importante, pero no definitivo.


En ningun momento he intentado afirmar que un sistema sea mejor o peor que otro. Cada sistema tienes sus ventajas e inconvenientes, y es responsabilidad de cada uno decidir para cada proyecto en concreto lo que es mas apropiado.
Pondre otra analogia, seguramente un ferrari que corra a 300 km/h sera muy bueno en Alemania donde en las autopistas no hay limite de velocidad. Pero para ir por el medio del monte es preferible un todoterreno ;)


Los servidores de datos relacionales pueden hacer muchas más cosas que las que se pueden hacer con un motor basado en archivos indizados, a pesar que en determinadas circunstancias estos últimos puedan tener un rendimiento (en cuanto a velocidad de acceso) superior a los primeros.
Saludos.

Solo puntualizar que los servidores de base de datos cliente/servidor se basan igualmente en archivos indizados, solo que el acceso a las tablas e indices las hace exclusivamente el servidor. En cuanto a servidores de datos relacionales, tan relacional puede ser un sistema cliente/servidor como uno basado en tablas planas. La forma de acceso no define si un sistema es relacional o no ;)

Saludos
Miguel

[kinobi]

Solo puntualizar que los servidores de base de datos cliente/servidor se basan igualmente en archivos indizados, solo que el acceso a las tablas e indices las hace exclusivamente el servidor. En cuanto a servidores de datos relacionales, tan relacional puede ser un sistema cliente/servidor como uno basado en tablas planas. La forma de acceso no define si un sistema es relacional o no ;)

Ciertamente. Debería haber puntualizado que un sistema como Paradox se queda ahí, en un sistema de archivos indizados... exclusivamente. No pretendía negar la existencia de archivos indizados en otro tipo de motores.

En cuanto al asunto de los servidores de datos relacionales, no trataba de decir que un motor que no funcione bajo una arquitectura cliente/servidor no pueda serlo (relacional). Ahora bien, puestos a puntualizar, maticemos que un motor de datos sólo puede ser (verdaderamente) relacional si cumple las 12 de reglas de Codd y, en este caso, Paradox no las cumple en su totalidad, y por este motivo debería ser excluido de esta categoría de motores (relacionales).

Saludos.

[Mick]

En cuanto al asunto de los servidores de datos relacionales, no trataba de decir que un motor que no funcione bajo una arquitectura cliente/servidor no pueda serlo (relacional). Ahora bien, puestos a puntualizar, maticemos que un motor de datos sólo puede ser (verdaderamente) relacional si cumple las 12 de reglas de Codd y, en este caso, Paradox no las cumple en su totalidad, y por este motivo debería ser excluido de esta categoría de motores (relacionales).
Saludos.

He dicho en un post anterior que seria mas "cuidadoso": por eso no he mencionado paradox, literalmente he dicho "tan relacional puede ser un sistema cliente/servidor como uno basado en tablas planas".
En ningun momento he afirmado que paradox sea o no sea relacional.

Independientemente de esto no conozco ningun sistema que cumpla fielmente todas las reglas de codd.

Saludos
Miguel

PD: Esto se esta volviendo un dialogo para besugos XD

[kinobi]

Hola,

He dicho en un post anterior que seria mas "cuidadoso": por eso no he mencionado paradox, literalmente he dicho "tan relacional puede ser un sistema cliente/servidor como uno basado en tablas planas".
En ningun momento he afirmado que paradox sea o no sea relacional.
Yo, que también he sido cuidadoso con mi afirmación sobre Paradox, lo he citado expresamente porque el hilo comenzaba con una pregunta sobre este motor, y trataba de manterme en el tema.

Independientemente de esto no conozco ningun sistema que cumpla fielmente todas las reglas de codd.
Yo sí. El mismo Firebird/InterBase que se ha citado en el hilo, las cumple. Al menos tal como las formuló Codd en los 80.

PD: Esto se esta volviendo un dialogo para besugos XD
No hay problema. Por mí se ha terminado.

Saludos.

[CFPA86]

Hola foro, en verdan nunca crei que un hilo posteado por mi recibiera de parte de ustedes tanta acogida en verda les AGRADEZCO por todos sus comentarios consultare mas detenidamente para migrar de paradox (aunque buena me parecio haber leido en ocasiones sobre que acoge muy pocos registros), a firebird, usar PHP.
Les contare y le consultare sobre como me va con este gran proyecto, y nuevamente MUCHAS GRACIAS no me han defraudado.

Chaooooooooooooooooooooooooooo