es bueno paradox para una red?

[maruenda]

hola a tod@s. bueno, estoy leyendo el libro la cara oculta de delphi 4, y me parece muy interesante. pero me surge una duda. para trabajar en una red, es aconsejable paradox, o es una base de datos mas para trabajar en modo local.? yo estoy haciendo una aplicacion sobre paradox, y me gustaria antes de avanzar mas, si voy a tener algun tipo de problema :confused:

[eduarcol]

pues si es bueno, pero acuerdate que paradox es un gestor de tablas planas no de base de datos por lo que tiene limitaciones en el rendimiento, ahora si tu aplicacion no maneja gran numero de transacciones si lo podrias utilizar, pero buscate en el link de manuales el Manual de Paradox en Red ahi tienes algo para comenzar

[maruenda]

gracias por el comentario,pero me has dejado igual que estaba. ¿ que es una tabla plana? ¿ cual es la diferencia con una base de datos ? gracias :confused:

[eduarcol]

Pues mira una tabla plana es un simple archivo, con un encabezado que delimita la informacion guardada, una tabla corresponde a una sola entidad, por ejemplo: Clientes. Mientras una base de datos es un conjunto de tablas con informacion de relaciones, trigguers y todas esas cosas. Entiendo que no es una informacion muy buena pero seguro q en un buen libr de desarrollo de sistemas habra mejor info

[mlara]

Qué tal esto:

Una aplicación e base de datos (Paradox) escrita y compilada en Delphi 7.

La base de datos tiene 35 tablas, en total 199 archivos (se ha respetado el diseño. A parte de los índices existen muchas restricciones de clave foránea, es decir muchas relaciones entre tablas, además de algunas restricciones CHECK, se decir verificaciones de campo. De ahí el número de archivos.).

La aplicación funciona muy bien en modo local, pero cuando la base de datos crece (hay una tabla que en alcanza por año fácilmente los 80.000 registros y hasta más cuando el sistema está en producción), la aplicación se vuelve un poco lenta sobre todo generando reportes con Quick Report, cuando se construyen reportes de mediana complejidad (maestro detalle pero trabajando con el evento OnNeedData).

pero bueno, el asunto es Paradox en red.

El sistema que he implementado (en unos tres años de trabajo) realiza consultas que no son tan sencillas pero igual son consultas SQL que se realizan usando componentes TQuery. Esto asegura que la información está protegida, incluso cuando se va la energía (aunque no es garantía total, todo depende de cómo se usen los componentes).

Por requerimientos de nuestros clientes se quizo trabajar con este sistema en red. Como en nuestra empresa usamos nuestro propio software, en producción probamos el desempeño, y el resultado:

Para realizar consultas desde clientes, perfecto. Sólo que demoraba un poco más con la cuestión de los reportes.

Para realizar inserciones, actualizaciones, y eliminaciones no lo recomiendo, sobre todo si varios clientes trabajan sobre las mismas tablas. No es cuestión de manejo de transacciones. Cuando se conectaban dos clientes y empezaban a trabajar, en un momento determinado fallaba uno, y luego... a revisar la base de datos. Diagnóstico: Estructura de base de datos dañada. Aunque no se perdían registros, empezaba a funcionar mal, incluso trabajando ahora en sólo modo local. Solución: Ejecutar una buena herramienta para reparar tablas Paradox. Si esto no funcionaba entonces había que reconstruir la tabla dañada y hacer un trasteo de información. En conclusión, no lo recomiendo para sistemas de mediana complejidad.

Nota. Hace un par de años trabajé en otro sistema, pero este pequeño en relación al que he comentado. En red no tenía problemas (con más de 10 equipos y hasta 25), pero la diferencia es que los clientes insertaban registros en tablas Paradox sin hacer absolutamente ningún tipo de consulta (un cliente muy simple), y esto lo hacía con componentes TTable. Pero ojo: Si un equipo se bloqueaba, o se iba la energía... de nuevo problemas.

Espero sirva de algo.

[eduarcol]

Es una informacion muy completa :) creo que con eso debe saber cuales son las limitaciones del trabajo, y de alli tomar una decision comparando con sus requerimientos