Desventajas de las DBF de VFP

[Jonhyrey]

Hola a tod@s

En la empresa donde estoy trabajando, se implementará un sistema ERP para sustituir todas las aplicaciones de Vsual FoxPro que hay. Son como 5 sistemas de fox que serán reemplazados. Para esto, nos han pedido que construyamos una presentación en powerpoint para la junta directiva explicando cada una de las desventajas de los sistemas actuales; ya hicimos la parte que nos corresponde y necesitamos incluir las desventajas de las DBF como gestor principal de las bases de datos.

A ver si ustedes me pueden ayudar con algunas.

Muchas gracias y saludos a todos

[bismarck73]

Disadvantages of the DBF
Safety
While it occurs much less frequently with the more recent versions of VFP, individual data files can
become corrupt due to network or workstation interruptions. When such corruptions occur, often a
third-party utility must be used to correct the problem. Further, since typically all program users have
full rights to the directory containing the data, an individual could (accidentally or maliciously) delete
or overwrite one or more data files, or modify a data file from outside the VFP application, potentially
introducing errors or corruption. There is no inherent protection of the DBF from outside application
access.

Security
There is no provision for user-specific rights to DBF files other than that provided by the VFP
application. Anyone with sufficient access to the application's data directory can copy any file or open
it using an external tool (such as Access or Excel).

Data Integrity
While later versions of VFP have added the ability to enforce some forms of data integrity at the
datafile level, these enhancements do not have the performance or robustness of those found in SQLS.
In short, they are ways to tack-on these abilities to an existing data format. Therefore, a VFP DBF
application system does not have any data integrity enforcement other than what the programmer
remembers to code within the application. If someone accesses the data from outside the application
then all data integrity checks that might be found in a VFP DBF application are bypassed.

Remote and Slow Access
Since DBFs reside on a file server, performance of the application is based partly on the speed of the
file server's disk system and network, with the processing power of the local computer workstation
being a significant additional factor.
For example: when a user requests a list of orders for the current month, the user's workstation must
sort through all rows (assume a total of 500,000 orders in the file for this example). This will require,
at best, index data for all 500,000 records to be dragged across the network from the file server to the
user's workstation if there is an existing index on the requested date column. At worst, if the query
involves non-indexed columns, a great deal of that many megabytes of data will have to come across
the network and be processed by the user's workstation, where all of the processing is performed (none
is performed on the file server).
This architecture works well on fast networks with moderately-powerful workstations. If the data is on
a separate network or separated by a slow infrastructure, data access and apparent performance degrade substantially.
There is no extraordinary provision for remote access to DBF files, just as there isn't for Excel XLS
files. Techniques such as RDC or terminal services can be used.

[Jonhyrey]

Muchas Gracias, estas serán de las primeras. Alguien conoce más?

[juanca]

Muchas Gracias, estas serán de las primeras. Alguien conoce más?

Las DBF son archivos locales, un RDBMS es mas robusto al tener concurrencia de conexiones (en red), capacidad de recuperacion de datos, administracion remota y respaldo de la bases (en linea o fuera de linea, depende de la base).

Date una vuelta en wikipedia para mas info.

Si no molesto, que ERP van a usar?? (SAP??) y que base (MSSQL??)

[rcguillen]

El proveedor del ERP deberia de darte los pro de cambiar el sistema, dandote las desventejas de tener bases de Fox
A ellos (proveedor) mas q nadie le conviene este asunto.

Pero si se los han pedido como opinion interna te dire lo siguiente

1 - Bases de fox es vulnerable a cambios de voltaje, podrias tener inconsistencia en la informacion
2 - Si se va la energia pierdes datos y posiblemente se te dañe la data.
3 - Hay cero seguridad :
4 - Para poder ejecutar aplicaciones en red, tienes q compartir una carpeta con eso cualquier podria entrar y borrarte dichos datos y dejarte sin nada.
5 - Cuando se reindexa si un indice esta malo por los puntos 1 y 2 posiblemente te borre dicho indice de su estructura, dandote asi problemas de integridad y demas.
6 - tienes q estar en constante mantenimiento a la base de datos para asegurarte q no se pierda relaciones y demas.
7 - lentitud con altos volumenes de datos.

[Jonhyrey]

Muchas gracias por la información!!!

Si no molesto, que ERP van a usar?? (SAP??) y que base (MSSQL??)

Pues fijate que vamos a implementar Intellisis, un ERP mexicano que se adapta bien a lo que necesitamos. Ahhh y la BD es MSSQL.
Nos tocó hacer esto a nosotros porque digamos que el proveedor no se ha involucrado mucho en los sistemas que tenemos en funcionamiento actualmente. Y tenemos que demostrarle a los señores de la junta, que no van a botar su dinero por gusto.

Hey muchas gracias por sus aportes bismarck73, juanca y rcguillen; de verdad que me han servido mucho sus aportes.

Saludos

[juanca]

Muchas gracias por la información!!!
Pues fijate que vamos a implementar Intellisis, un ERP mexicano que se adapta bien a lo que necesitamos. Ahhh y la BD es MSSQL.
Nos tocó hacer esto a nosotros porque digamos que el proveedor no se ha involucrado mucho en los sistemas que tenemos en funcionamiento actualmente. Y tenemos que demostrarle a los señores de la junta, que no van a botar su dinero por gusto.

Hey muchas gracias por sus aportes bismarck73, juanca y rcguillen; de verdad que me han servido mucho sus aportes.

Saludos

Como consejo, en la compra de paquetes asi siempre hay que verificar que cuando menos el codigo de el ERP se pueda modificar en casa, te lo cuento porque el SAP es algo duro en eso y solo puede modificarse con unas herramientas que ellos tienen pero que no te incluyen en la venta.

Y si no van a tocar uds el codigo, hagan que el proveedor les haga todos los cambios pero dandole un tiempo necesario para hacer las pruebas y correcciones. Ya me he topado en auditorias que cuando implementan un ERP lo hacen en tiempos bien cortos y luego los clientes se quedan a medio tiro porque no le dieron seguimiento a los cambios para que el software quedara a punto, asi que les toco pagar mas por las modificaciones que por cierto el contrato de mantenimiento no cubria.