viernes, agosto 03, 2007

¿ Porqué usar ADS y no un SQL ?

Esta comentario viene al caso a raíz de un comentario mío en el foro de FiveTech Software, sobre ADS, hice ahí una explicación bastante extensa y puse algunos links a historias de éxito con ADS de nuestros clientes, curiosamente esos links desaparecieron "misteriosamente" a las pocas horas de haber sido publicados (tengo las bitácoras de acceso a blogspot para demostrarlo, entre la hora de la publicación y 2 horas después de la misma Objeto Persistente recibió casi el doble de visitas que lo recibimos en un día normal en el mismo horario, las referencias eran a los links publicados en el foro) y que conste que ninguno de esos links hablaba de ningún producto "ajeno", entiéndase de Xailer, mas bien todos eran historia relativas a ADS, FiveWin y a xHarbour.

Ok ok ok, es SU foro y ellos tienen derecho a permitir la publicación de lo que quieran, ahí no voy a entrar.

Bien dejando a un lado la censura, entremos en materia.... ¿ Porqué usar ADS y no un SQL ?

Antes de meternos mas profundamente en esto, tenemos que diferenciar entre lo que es un SQL y lo que es la tecnología Cliente/Servidor, términos que usualmente son confundidos por los usuarios, un SQL no necesariamente es cliente/servidor, como es el caso de SQL Lite o Access, y viceversa, un Cliente/Servidor no es forzosa ni necesariamente basado en SQL, como lo es ADS.

Clarificando: SQL es un LENGUAJE DE PROGRAMACION, no es una tecnología de acceso a datos, el hecho de que muchos sistemas gestores de bases de datos relacionales (SGBDR) utilicen SQL como su lenguaje de acceso a los datos, no tiene absolutamente nada que ver con la tecnología sobre la cual están construidos, que es la tecnología Cliente/Servidor.

Pero bueno, ¿ qué es Cliente/Servidor?. Este término se refiere a una tecnología, una metodología de acceso a datos, en la cual se identifican claramente 2 elementos: el "Cliente", es decir, el programa que hará uso de lo datos y el "Servidor", que es la entidad encargada de "manejar, administrar y controlar" los datos solicitados por el cliente. En ambos casos, tanto el Cliente como el Servidor son piezas de software.

Simplificando el modelo, la cosa funciona así: El CLIENTE, programa ejecutándose en una estación de trabajo, ya sea dentro de una red local o remota, vía Internet, realiza una serie de "peticiones" de información al SERVIDOR (aquí es donde entra el famoso "SQL", que es el lenguaje en el que comúnmente se hacen estas peticiones), el servidor (programa ejecutándose en un servidor de hardware) recibe dichas peticiones, se encarga de manipular, filtrar, ordenar y organizar las tablas almacenadas en el disco duro del servidor de hardware, y enviar de vuelta al Cliente los datos solicitados, pero atención se envían únicamente los datos filtrados, organizados y ordenados de acuerdo a como el cliente hizo la petición, nunca se envían las tablas completas ni se trabaja directamente sobre ellas, siempre existe un “mediador” entre el cliente y los datos: el “servidor”.

Todo el trabajo de acceso a datos recae en el SERVIDOR, MySQL, SQL Server, Informix, Oracle y el mismo ADS son ejemplos de Servidores de datos.

En el modelo tradicional XBase y en cualquier otro modelo que no sea "cliente/servidor", Access incluido, se opera bajo lo que se conoce como "Arquitectura Distribuida", ¿ qué es esto ?, de entrada es lo opuesto a Cliente/Servidor, es una tecnología mediante la cual los datos son copiados desde el disco duro del servidor (hardware) al disco duro de la estación de trabajo, la manipulación de los datos se realiza de manera local, usando los recursos de la propia estación de trabajo y luego los datos son enviados de vuelta al servidor de hardware para su actualización y almacenamiento. Esto quiere decir, que si tu tienes un DBF que mida 10 MBytes de tamaño, los 10MBytes son copiados desde el servidor hasta la estación de trabajo, tantas veces como hagas “USE” de esa tabla y tantas veces como usuarios tengas en tu red que hagan uso de la misma tabla al mismo tiempo, lo cual provoca, de entrada, tráfico en los cables de la red, y por su puesto colisiones, ya que al hacer un "commit" estas enviando de vuelta TODA la información de regreso al servidor, es por esta razón que usar DBFs sobre VPNs no es para nada una buena idea, este modelo de trabajo tampoco aprovecha el poder de procesamiento del servidor, así que aunque tengas un servidor super potente, con dos procesadores Pentium Xeon Dual Core Non Plus Ultra etc. etc. etc., tropocientos mil Gigas de Memoria y cableado de 1 Gigabit, si no tienes tecnología cliente/servidor, todo ese invento no te sirve para nada, tendrás simplemente un disco duro compartido, alojado en un servidor desaprovechado, y con una velocidad de red que solo hará que tus colisiones se realicen mas rápido.

Hablemos ahora de ADS. ADS es un servidor de datos, es decir, un programa que se instala en un servidor de hardware y que hará la administración de los datos tal cual lo hacen productos como MySQL, FireBird, SQL Server, Informix, Sybase (de hecho ADS es un producto de Sybase).

¿ Cual es la diferencia entonces entre ADS y cualquier otro producto ?, bien, la diferencia radica en que mientras otros productos tienen sus propios formatos de almacenamiento nativo de datos, ADS utiliza archivos DBFs con índices NTX o CDX para almacenar los datos, también provee de un formato propietario de almacenamiento que utiliza archivos de datos en formato ADT, con índices ADI y campos memo ADM, esa es la "pequeña" diferencia que hace que ADS sea la solución ideal cuando necesites el poder del cliente servidor con archivos DBFs.

¿ ADS hace lo que hacen "los otros" sistemas como MySQL, SQL Server, Oracle, etc ?, si, cuenta con soporte a todo lo que puedes encontrar en cualquier otro servidor de base de datos, incluyendo: replicación de datos (tener 2 servidores con los mismos datos “en espejo”) transacciones, integridad referencial, diccionario de datos, acceso por internet, procesos almacenados, triggers, respaldo automático, control de acceso a usuarios, incluyendo restricciones por usuario, por tabla y hasta por campo, también incluye protección de datos utilizando mecanismos de ocultamiento y de encriptación de los mismos.

Otra ventaja que ofrece ADS es la multiplataforma, así como para ejecutar MySQL requieres de un servidor Linux o Windows, no puedes ejecutarlo en Novell (aunque la ultima versión de Novell Linux ya ofrece esta posibilidad), un SQL Server no corre mas que en Windows, no te sirve para Novell o para Linux, y un Oracle está fuera de toda posibilidad por el precio, ADS provee de servidores para cualquier plataforma, hay ADS para Linux, para Windows y para Novell, el precio del servidor y del licenciamiento es igual para todas las plataformas.

Hablemos ahora de la programación. Mientras que en la mayoría de los servidores de base de datos necesitas programar el acceso a datos usando SQL, con ADS no ocurre eso, el acceso a los datos se realizan utilizando la misma metodología del lenguaje de programación que estés usando, para ello ADS provee una serie de "clientes" grautitos (excepto uno, el de Xbase++ es de paga), estos clientes pueden ser DLLs, VCLs, LIBs, JARs, etc. que se tienen que incluir como parte de tu EXE dependiendo de tu lenguaje de programación.

En este punto lo importante es que ADS se adapta a tu lenguaje de programación, usando las mismas metodologías que utilice tu lenguaje para acceder a los datos, lo que no te obliga a usar forzosamente SQL para acceder a ellos, de tal manera que el impacto en la programación es mínimo, no tienes que cambiar casi nada de tu código fuente actual (sea cual sea el lenguaje de programación) porque ADS se adapta a la forma en que tu lenguaje acceda a los datos, por ejemplo si trabajas en C, C++, Visual Basic, etc, tienes un cliente ODBC y un ADO provider para ADS, si trabajas con VisualStudio, tienes un proveedor ADO.NET, si trabajas con Delphi en Windows o Kylix en Linux, tienes un TDataSet ADS, si trabajas con Java tienes un JDBC nivel 2, si utilizas algún lenguaje para crear páginas dinámicas para Internet, tienes un cliente ASP y otro PHP tanto para Windows como para Linux, si eres usuario de XBase++, tienes un DBE, si eres usuario de Clipper o Visual Objects, tienes un RDD, y si eres usuario de xHarbour, la comunidad de desarrolladores ha creado el RddADS que te permite el acceso a los datos tanto desde aplicaciones modo consola como desde cualquier interfaz gráfica como Xailer (el cual cuenta con un DataSet ADS nativo), Fivewin, MiniGUI, etc.

Adicionalmente, puedes combinar lo mejor de ambos mundos en el mismo EXE (solo con aplicaciones de 32 bits, no es posible hacerlo a 16 bits), el manejo de los datos usando comandos Xbase comunes y corrientes se puede combinar con queries SQL ya que estos últimos facilitan enormemente el acceso a datos: la combinación de datos de tablas distintas, las relaciones entre los datos y las ordenaciones de los mismos.

Por ejemplo, si estás trabajando con (x)Harbour, puedes hacer un USE TABLA SHARED NEW, y al mismo tiempo puedes “abir” un query del tipo SELECT * FROM TABLA WHERE CONDICION sobre DBFs, el resultado de la ejecución de este query SQL se abrirá en un "area" nueva, podrás hacer un SELECT para moverte al área nueva y luego podrás hacerle un browse directamente a los datos, modificarlos, borrarlos, ingresar nuevos, etc.

Los programadores que abandonan el modelo de archivos DBFs lo hacen por varios motivos, mismos que son totalmente eliminados con el uso de ADS:

* Corrupción de índices: ADS elimina totalmente la corrupción de índices, tengo clientes que llevan 4 o 5 años sin regenerar un índice, aunque la mayoría realiza la reindexación de las tablas por lo menos una vez al mes, lo hacen solo por mantenimiento, en general no es necesario hacerlo.

Solo como comentario adicional, la regeneración de índices con ADS es mas de 10 veces mas rápida que con el Clipper-(x)Harbour normal, una generación de índices que lleve mas de una hora, queda reducida a 1 o 2 minutos, ya que es el servidor, sí sí, tu mega servidor con 2 procesadores y tropocientos gigas de memoria quien se encarga de eso, sacándole el máximo jugo a la memoria y al procesador del servidor, al no haber transferencia entre el servidor y la estación de trabajo, la reindexación se realiza de manera mas rápida.

* Con muchos usuarios los DBFs se vuelven lentos: Lo cual es lógico, entre mas grandes sean las tablas y entre mas usuarios estén accediendo a ellas, crece el tráfico en la red (recuerda: en el modelo tradicional los datos se copian del servidor a la estación de trabajo y viceversa), esto no sucede con ADS, ya que las estaciones de trabajo no tienen acceso directo a las tablas de datos, el servidor ADS es quien se encarga de procesar las peticiones de las estaciones de trabajo y enviarles de regreso "imagenes" de los datos reales, este proceso se realiza de manera tan rápida, que para la estación de trabajo (y para el programador mismo) da la impresión de estar utilizando el modelo tradicional de acceso a datos, esto de entrada reduce el tráfico en la red, porque en vez de enviar megas y megas de datos por el cable de la red se envían unos pocos bytes, teniendo un tiempo de respuesta excelente y permitiendo incluso el acceso de los datos via internet.

Por otro lado ADS realiza “buffering” cada vez que un usuario hace petición de datos nuevos, guardando en la memoria RAM del servidor los datos mas comúnmente utilizados por los sistemas a fin de tenerlos disponibles de manera mas rápida cuando un usuario haga la petición de los mismos, curiosamente, entre mas usuarios estén usando los datos, la(s) aplicación(es) se ejecutará(n) mas rápidamente puesto que ADS mantendrá en memoria una copia de los datos mas solicitados por todos los usuarios, obviamente el acceso a memoria lleva menos tiempo que el acceso a disco.

* Los DBFs no son "seguros". Este aspecto es el mas importante a considerar en una era donde "información es poder", y quienes afirmen que los DBFs carecen de seguridad tienen razón, para empezar, en aplicaciones para red tienes que compartir la carpeta del servidor donde están los datos, eso de por sí ya es un riesgo de seguridad, luego tienes que darle acceso al usuario de lectura y escritura a dicha carpeta, porque si no, el progrmaa no puede modificar los datos, eso ya es el no va mas de la inseguridad, un día de estos cualquier usuario resentido le saca una copia a los datos y se los lleva a su casa para venderlos a la competencia, borra los DBFs de una carpeta o los altera con un programa externo y no hay nada que puedas hacer porque al ser el formato DBF sumamente popular, muchos programas proveen acceso a dicho formato de archivo, como por ejemplo Access y Excel, dejando a la vista toda tu información. Con ADS no ocurre eso, porque ADS provee 4 mecanismos de seguridad para tus tablas DBF:

1) Protección por cambio de formato: ADS maneja su propio formato de archivos, el ADT, que aunque internamente es distinto, a nivel programación se maneja exactamente igual que un DBF, de tal forma que USE, APPEND, REPLACE, etc funcionan igual sobre los ADT que sobre los DBFs, hay varias ventajas en usar este tipo de archivo, por ejemplo tienes nuevos tipos de datos como son los timedate, los time, los campos “autoincrementales” y los tipo BLOB que te servirán para almacenar cosas binarias, como imágenes, documentos de Office, etc. además los ADTs son mas rápidos en el acceso a los datos que los DBFs además de ser mas pequeños en el almacenamiento de datos que un DBF con la misma estructura y la misma cantidad de registros, su ventaja principal en el aspecto seguridad radica en que este tipo de archivo solo puede ser leído por un “cliente” ADS, en este caso tu programa. Adicionalmente ADS provee de una herramienta tipo DBU Visual para manejar dichos archivos: el Advantage Data Architech, que es gratuito, te sirve tanto para tablas DBF con NTX y CDX como para tablas ADT, y que puedes descargar haciendo clic aquí. El ARC (como se le conoce al Advantage Data Architech) te permite además de visualizar los datos, convertirlos de DBF a ADT y viceversa y manipularlos usando SQL.

2) Protección por “ocultamiento”: ADS no necesita que tus datos estén en una carpeta compartida de tu servidor, simplemente quítale los privilegio de acceso a la carpeta donde están alojados los datos a todos los usuarios y listo, al ser ADS un servicio corriendo dentro del mismo servidor de hardware, tiene acceso a TODOS los directorios del mismo, recuerda: el cliente solo hace peticiones al servidor, y es el servidor quien lee los datos del disco y los envía de vuelta al cliente, por lo tanto, el cliente no necesita tener acceso a los datos directamente, de hecho cuando implementas esta forma de protección, el usuario desde la estación de trabajo no podrá ver la carpeta donde están almacenados los datos, ya que no está compartida, por lo mismo no podrá acceder a ella, no podrá copiarlos, borrarlos ni manipularlos con ninguna herramienta externa.

3) Protección por encriptamiento: ADS provee de un poderoso motor de encriptamiento de 128 bits, que funciona tanto sobre archivos DBFs como sobre archivos ADTs. Este mecanismo de encriptamiento funciona en base a un “password” asignado por el programador al momento de diseñar cada tabla individual, de tal forma que cada tabla tiene un password único para desencriptar los datos. A diferencia de otros mecanismos de encriptación donde solo se pueden encriptar los campos tipos carácter, ADS encripta TODO tipo de campos: numéricos, lógicos, fecha, carácter, memo, TODO.

El encriptamiento es realizado por el servidor de datos, de tal forma que los datos siempre están almacenados como encriptados, cuando un usuario pide un dato, el servidor lo toma, lo desencripta y le envía al cliente la información desencriptada, cuando un cliente modifica un dato o agrega datos nuevos, la información llega al servidor de base de datos, este la encripta la guarda encriptada.

ADS además encripta también la cabecera del archivo de datos, lo cual impide que aunque sea un DBF pueda ser leído o alterado por cualquier otra herramienta externa.

4) Protección por tipo de usuario: ADS provee un mecanismo de organización de tablas llamado “diccionario de datos”, este mecanismo nos permite crear usuarios individuales y otorgarles permisos de acceso a los datos, tal cual se hace en cualquier otro sistema basado en SQL, nosotros podemos crear usuarios y asignarles privilegios de solo lectura, lectura / escritura o bloquear totalmente el acceso a las tablas, todo dependiendo del tipo de usuario que nosotros creemos.

El uso del “diccionario de datos” también permite la habilitación del acceso por Internet a los datos, ya que es usando el diccionario de datos, la manera en la que indicaremos que usuarios tienen acceso a los datos vía Internet.

Todo esto suena muy maravilloso, ¿ donde está el truco ?, bien el truco está en el precio del producto, dependiendo del punto de vista, ADS puede ser un producto extremadamente caro, o extremadamente barato, júzgalo tu mismo, el costo por estación de trabajo oscila entre 150.00 y 175.00 dólares por cada estación de trabajo cliente que queramos usar con ADS, ya sea dentro de la LAN o vía Internet.

El problema mas fuerte económicamente hablando es que no hay flexibilidad en las licencias, siempre van en los mismos bloques 5, 10, 15, 25, 50, 100, 250 y 1000, así por ejemplo si tienes 7 usuarios tienes que comprar forzosamente una de 10, si tienes 75 usuarios tienes que comprar la de 100, lo mas patético es que si tienes 16, 26 o 51, tienes que comprar la inmediata superior, en pocas palabras ADS no es barato, pero tampoco es para cualquier tipo de aplicación.

El cliente típico de ADS es aquella entidad que tiene grandes volúmenes de información aunque esta sea manipulada por pocos usuarios, el modelo contrario también es susceptible de implementación de ADS: muchos usuarios con poca información, pero en general el modelo se aplica para redes con 10 o mas usuarios y con grandes volúmenes de información, como comentaba alguna vez, tengo clientes con mas de 70 millones de registros todos metidos en el mismo DBF.

ADS compite en precio con productos comerciales como SQL Server, Informix, Oracle, etc, es muchísimo mas barato que un SQL Server y no digamos que un Oracle, mas no compite en precio con las herramientas OpenSource como MySQL, PostgreSQL o FireBird, sin embargo ADS si compite contra estas en un aspecto muy importante: Tiempo de implementación.

Si por ejemplo ya tienes un sistema estable, funcionando bajo DBFs, el paso lógico para darle más estabilidad y poder es usar ADS, no moverlo a otra plataforma de almacenamiento de datos.

Para moverte a un producto Open Source o para cualquier otro sistema gestor de base de datos basado en SQL, tienes un precio que pagar: TIEMPO.

Para empezar tienes que hacer una reingeniería de la base de datos (es una muy mala idea copiarse la estructuras DBFs dentro de un servidor basado en SQL y luego intentar hacer que funcionen como estábamos acostumbrados), una vez rediseñada la base de datos, tienes que volver a reescribir TODO el programa, bueno, no todo, solo las pantallas de captura de información, los reportes y el acceso a los datos para que funcionen usando SQL, eso si no pensamos que mejor vamos a hacer todo con procesos almacenados (que sería la mejor opción) ¿ cuanto tiempo te va a llevar hacer todo esto ?, en mi experiencia este cambio te va a llevar entre 6 a 18 meses, con mucha suerte, dependiendo de la complejidad del sistema, mientras la operación tiene que continuar, ingenuamente creerás que te vas a ahorrar dinero al no tener que desembolsar el costo de la licencia de ADS, pero eso no es cierto, vas a tener que invertir tiempo en capacitación (aunque compres libros y bajes literatura de internet vas a tener que dedicar tiempo a leer), vas a tener que invertir tiempo en reprogramar todo, vas a tener que invertir tiempo en experimentar, ¿ y todo por el mismo dinero ?.

ADS quizá consideres que es caro, sin embargo el tiempo de implementación es muy corto, una migración “Express” a ADS se puede hacer en 2 días tranquilamente, pero si quieres implementar todo el poder de ADS en un programa, esto no tiene que llevarte mas de un mes y mientras, puedes estar trabajando con tus herramientas “viejas” ya que ADS provee compatibilidad con programas hechos en Clipper, FoxPro, etc.

Si quieres mas información sobre ADS, visita nuestra página de Información sobre ADS, realmente merce la pena poner en la balanza la decisión de pagar el precio del ADS pero tener un programa “a prueba de balas” en poco tiempo, o bien, invertir tiempo y dinero en tratar de implementar cualquier otra herramienta de manipulación de datos, aunque esta sea regalada.

8 comentarios:

Jose A. Suarez dijo...

René:

Con todos los respetos: ¡NO!.

ADS es un apaño para seguir usando DBF's.

Los motores de bases de datos basados en SQL aportan muchísima potencia a la hora de obtener resultados, SQL es un lenguaje pensado para manejar datos.

Por otro lado SQL con ADS es, con todos los respetos, UNA TREMENDA CHAPUZA, lento, de difícil implementación y que de igual manera tienes que cambiar mucho de tu forma de trabajo. Y ya puestos, para usar SQL con ADS, mejor usar un motor SQL.

¡NO, NO y NO! Vamos de una vez a dejar de confundir al personal y a hablar claro:

ADS: Apaño para no dejar tus DBF's de toda la vida y seguir usando tu forma de programar. ¿Reusabilidad del código? Pues la verdad, poco y mal. Y sigues teniendo que mantener indices para casi todo lo que necesites de ordenación, filtros con scopes, etc. El SQL de ADS no es totalmente compatible con SQL estándar.

SQL: Lenguaje de programación orientado a manejo de datos. Muy potente. Muy rápido. No son necesarias tantos indices, las consultas bien planteadas resuelven todos los casos. Quizá algo incómodo para los usuarios de DBF's acostumbrados a los USE.

Otra de las ventajas del SQL es que lo tienes en los servidores de Internet, ya sea MySQL, SQL Server, Postgre, etc. Lo que facilita la interactividad de aplicaciones de escritorio con aplicaciones web.

El consejo: "Si quieres seguir usando DBF's, usa ADS, te quedarás en tu mundo DBF para siempre."

La moraleja: "Olvida las DBF de una vez y atrévete a coger el toro por los cuernos, SQL es el lenguaje para manejo de datos más extendido y aceptado, pese a quien le pese."

Rene Flores dijo...

Jose Alfonso:

Difiero de tu opinion, ADS te ofrece lo que cualquier motor de base de datos basado en SQL.

Si la gente no lo aprovecha es simplemente POR QUE NO SABE COMO UTILIZARLO, pero lo mismo pasa con cualquier motor SQL, tu mismo haz dicho que para utilizar bien un SQL hay que hacer una reingeniera de la base de datos.

Lo mismo sucede con ADS, si quieres trabajar tu metodologia XBase adelante, hazlo, si quieres usar SQL tendras que replantearte la manera de trabajar.

Por cierto, ADS tambien tiene servidor para Internet, actualmente estamos trabajando acceso via internet desde portatiles con tecnología 3G de telefonía movil, y enlazando sucursales remotas via ADSL con ADS.

Yo no digo que SQL sea malo, al contrario, yo mismo hago mucho trabajo en SQL pero con ADS por la facilidad que me da para combinar datos de distintas tablas y por la velocidad de filtraje de los datos.

Créeme sé perfectamente de lo que estoy hablando, tengo 10 años distribuyendo ADS, desde la versión 3.5 y tenemos mas de 2000 licencias instaladas en Novell, Linux y Windows XP, en todo caso, no tengo ningún cliente insatisfecho, o que me reclame que la solución no le ha valido.

Hemos quitado proyectos en Informix y los hemos sustituido por ADS, y adicionalmente tenemos certificados de Ford Motor Company donde ADS es una solución aceptada por el departamento de TI de Ford para implantar en los concesionarios.

Acepto perfectamente tu punto de vista, y perdona que insista, hoy por hoy ADS le planta cara a cualquier gestor de base de datos relacional.

Y te repito, si la gente no lo explota como debe, es porque no sabe como usarlo.

Rene Flores dijo...

Por cierto, otra cosa que olvide comentar:

ADS tiene un excelente, increible, estupendo servicio de soporte técnico, no dejan duda sin resolver, la base de conocimientos es bastante extensa y cualquiera puede tener acceso a ella en:

http://devzone.advantagedatabase.com

La documentación también es extensa y explicativa, y aclara muchísmas de las dudas que te puedan surgir en la programación.

La pega al respecto, es que todo está en inglés, por eso nosotros hemos desarrollado nuestra propia documentación, pero siempre es mejor el sitio de soporte porque tienes toda la información actualizada.

Israel Solis dijo...

Hola:

He sido programador xBase desde hace mas de 15 años, en muchas ocasiones había intentado "saltar" a otros lenguajes de programación y motor de base de datos mas "famosos" pensando que era la única manera de dar mas estabilidad y seguridad a mis bases de datos.

Lanzamos una aplicación comercial hace poco mas de 8 años y poco a poco fue tomando mucha fuerza en el mercado, llevando esto a mayores exigencias por parte de los usuarios. Durante este tiempo se fueron diversificando los clientes: clientes pequeños (un solo usuario en portatil) como clientes con 30 usuarios en red local e internet, clientes con PC's básicas con Windows 98 y otros con potentes máquinas con Windows Vista, Clientes con conocimientos muy básicos o casi nulos en el manejo de la PC y otros con departamentos de infortmática con gente especializada.

El punto es, llegó el momento que no hicimos la pregunta: ¿cómo seguir ofreciendo un software "enlatado" que no le complique al pequeño usuario con conocimientos y PC básica, y al mismo tiempo satisfacer las grandes exigencias del cliente que quiere aprovechar su red y su potente servidor?

Obviamente habría que cambiar de motor de base de datos, iniciamos manejando DBF/CDX que los usuarios pronto pusieron a prueba y encontraron las debilidades: abrían y alteraban los DBF con Excel, corrupción de índices, procesos de actualización de información "truncados" a medio camino, lentitud y riesgo en redes locales con muchos usuarios.

Nuestra desición fue cambiar a ADS por simples razones: Nuestros clientes pequeños puede seguir trabajando como lo hacen normalmente y, al mismo tiempo,
nuestros clientes grandes (mas demandantes) tienen todos los beneficios de la tecnología Cliente/Servidor. A nosotros nos permitió en menos de un mes tener una solución para ofrecer a todos nuestros clientes, con una inversion mínima de tiempo por parte de nosotros, lo que nos permite seguir inovando nuestro producto sin tener que estarnos preocupado por los problemas en la base de datos.

ADS nos resolvió todos los problemas: Seguridad, Velocidad, Estabilidad y, al mismo tiempo, flexibilidad: monousuario, LAN y WAN, en servidores Windows, Linux o Novell.

Porque no SQL? no lo sé con exactitud, no puedo hablar mucho de él ya que lo conozco muy poco (trabajé muy poco tiempo con él en una empresa) pero mi intención es ofrecer un software que tenga la flexibilidad de acuerdo al usuario.

Hay muchas herramientas y motores de bases de datos, tú elige, pero una cosa es cierta: "EL LENGUAJE/BASES DE DATOS NO HACEN AL BUEN PROGRAMADOR"


SALUDOS!!

Jose A. Suarez dijo...

A veces, cuando uno lee estas diferencias de opinión le entran ganar de volver a encerrarse en su mundo y dejar de divulgar lo que va aprendiendo y experimentando, sobre todo cuando algunos mantienen su postura desde el interés y otros la mantenemos desde el simple hecho.

En la empresa donde presto mis servicios se ha tomado la decisión, después de muchos meses de estudiar las diferentes posibilidades, de abandonar ADS e ir dirigiendo nuestros pasos hacia motores SQL más estándares.

Una de los motivos fue el que al crear una SELECT con el SQL de ADS usando GROUP BY nos obligaba a nombrar todos las columnas declaradas en SELECT para poder hacer el GROUP BY. Totalmente aterrador, la verdad.

Otro motivo ha sido, que llegado a cierto nivel de usuarios y tamaño de indices (que no de datos), con licencias de mas de 5, ADS se vuelve inconsistente, llegando a tener que reconstruir indices muchas veces. Además de lo ya comentado que hay que seguir manteniendo muchos indices al estilo DBF.

Para terminar derrotando a ADS, después de la experiencia de los GROUP BY, pasamos a MySQL los datos de un cliente, manteniendo las tablas exclusivamente con los indices de clave primaria, comparamos realizar la misma consulta SQL entre ADS y MySQL y la balanza se tiró hacia MySQL debido a la rapidez en servirnos los datos consultados, totalmente organizados para ser impresos sin mas complicaciones.

En fin, que lo que dije anteriormente, ADS está muy bien para los que no desean soltar las DBF y la programación con RDD's. Nada más. Para SQL (y Sybase tiene un producto excelente) están los motores SQL, ya sean cliente/servidor, como si no.

Y para terminar, donde está la comodidad de obtener un conjunto de datos con una SELECT listo para ser procesado, que se quiten todos los USE, DBUsearea(), DBSetOrder(), OrdSetFocus(), etc. del mundo.

Y lo dice alguien que defendió el sistema DBF en otros tiempos y con mas de 26 años de experiencia programado y diseñando sistemas de datos.

Carles Aubia dijo...

Hola,

Vamos a ver, yo creo que no se trata de entrar en una guerra de si és mejor el uso de ADS o de otro SGBDR. Son dos maneras de gestionar información muy distinta. Mi experiencia en la empresa dista de 20 años en distintos medios de programación. Estos van desde el uso de SQL en diferentes plataformas y servidores hasta el uso de ADS. Potentes entornos de gestión como SAP tienen su programación en su entorno Abap basada en SQL, sistemas con el uso de Oracle como motor, hasta sistemas menos potentes como MySql.
Pero tambien el uso de ADS nos ha facilitado mucho el trabajo diario en nuestros distintos ámbitos. Yo creo mucho en este producto y voy a intentar plasmar brevemente el porque:
- El producto ha evolucionado enormemente y si bien tiene la mala fama de ser caro, no todo es el valor en terminos de dinero, lo que se debe de tener en cuenta. Cuando uno tiene que realizar un programa debe de valorar otros aspectos, como el tiempo que uno esta diseñando tablas, modificando estructuras, importar, exportar datos, y sobre todo el mantenimiento que se debe realizar. ADS para esto ofrece una robustez total y su mantenimiento puede ser en ocasiones puntuales.
- Tenemos una aplicación que puede ser testeada y ejecutada en sistema local y sin cambiar nada del ejecutable, funcionar en modo Cliente/Servidor.
- Estoy de acuerdo que SQL esta enfocado y orientado al manejo de datos, y la flexibilidad que ofrece es muy amplia, pero NO estoy de acuerdo en que en ADS sea lento y de dificil implementación y esta afirmación es completamente falsa y sin base. No se a q te refieres con que cuesta mucho implementar, porque realmente es muy fàcil, y en cuanto a que no es compatible con el SQL standard tambien decirte que es falso, es mas, en la doc de ADS tambien te lo especifican "Advantage SQL support consists of most of the SQL-92 standard with ODBC extensions".
- Ofrece un sistema transaccional que va perfecto y un sistema de encryptacion de datos para q nadie le eche el ojo. Cuando oigo y leo muchas veces que la gente puede tocar, modificar, borrar y ver los datos de un dbf, me echo a reir porque es lo mismo q si das acceso a cualquier base de datos, en la que puedes meter mano de una manera facil.
- He leido por alli, q tambien con mas de 5 usuarios se vuelve inconsistente, y si claro, es cierto, y es el tipico problema de las Dbf y los datos distribuidos, pero es q realmente ADS esta pensado para el uso en entorno C/S, si bien te aporta tambien la funcionalidad de usarlo en modo local.
- Quizas uno de los puntos que mas me gustan del producto. Puedes usar las dos maneras de trabajar conjuntamente, el uso de acceso a los datos via comando xBase tradicionales junto con el acceso a potentes consultas via SQL, obteniendo asi un producto completamente híbrido y q se te puede adaptar de la mejor manera a tus problematicas. Nosotros los sistemas de consulta optamos muchas veces por el acceso via SQL porque da una mayor flexibilidad pero en el mantenimiento en si, muchas veces lo hacemos via xBase.
Hay un tip de Rene, q para mi es la clave de todo este debate. Mucha gente desconoce realmente las virtudes de este producto y simplemente cree q ADS es un RDD para C/S caro.
Tambien he notado en los foros, q durante los ultimos dos años, ha aparecido como una fiebre y un 'descubrimiento' por el acceso via SQL. Parece ser que sea ahora el mejor camino para hacer aplicativos potentes, robustos y consistentes -> Caray !!
Cada uno tiene sus experiencias y es normal q uno defienda el acceso via ADS o via MySql, el Visual Basic o el FWH o el Xailer, el Win o el Lin, ..., al final lo que a mi me importa es ofrecer una solución de una manera rápida, comoda, fiable y que me de seguridad a mi mismo. ADS es para mi un excelente produto, pese a quien le pese, y creo no estar anclado en el pasado.

Rene Flores dijo...

Carles:

Interesante tu experiencia en Bayer con ADS, la gran variedad de entornos que deben trabajar allí debe ser increíble.

A eso me refería yo, independientemente del SQL o del Xbase, el caso es que con ADS tienes VELOCIDAD de migración.

Que SQL es maravilloso, no lo pongo en duda ni tantito, de hecho yo descubí las maravillas de SQL hace como 5 años cuando forzosamente tuve que trabajar FiveWin 1.95 vía ODBC con Informix y lo he comentado con muchos colegas: usa SQL una semana y vas a olvidar de los DBFs.

También cabe recordar que SQL no es lo de "hoy", eso tiene mas de 30 años inventado, sin embargo la facilidad de uso del lenguaje ha hecho que siga trascendiendo hasta ahora, pero en realidad quien hace toda la magia no es el SQL, es lo que tiene detrás, el motor de base de datos es quien mueve todo el invento, y así como en el mundo automotriz, están los SQL "para todos" también existen los "ferraris" y "lamborighinis" de los motores de base de datos, si esto no fuera cierto, entonces Oracle no costaría la barbaridad que cuesta y FireBird no sería gratis, "algo" tiene que tener Oracle que es el mejor sistemas gestor de base de datos, y algo tiene que tener o dejar de tener FireBird, PostGre o MySQL para que los regalen, porque aunque todos usen SQL, el verdadero secreto esta debajo del capó.

Por otro lado, ahora resulta que lo verdaderamente moderno, lo de hoy, es ADO, y luego de que te pones a mirar lo que es ADO, te das cuenta que no es mas que el modelo XBASE, pero construido a base de SQL y eso solo en lo básico, en vez de hacer un USE TABLA, ahora haces un "recordset" proveniente de un Query, aunque al final y sin impotar como lo llames, "area", "cursor" o como quieras, tienes el mismo efecto que con Xbase, manejas todo por renglones, hace DO WHILE ! RecordSet:Eof() y tienes que hacer APPEND (RecordSet:AddNew()) y tienes que hacer COMMIT (RecordSEt:Update()) para dar de alta un registro, como en el Xbase de toda la vida, en pocas palabras, los que eramos obsoletos con nuestra forma de manejar los datos, hoy por hoy resulta que siempre hemos tenido la razón, y que lo moderno es trabajar como lo hemos venido haciendo nosotros desde hace mas de 20 años.

El caso de este post es porque debería escoger you ADS en ves de escoger un SQL, y la respuesta es simple: AHORRO DE TIEMPO

¿ Que pasa si eres una empresa que tiene 25, 50 o mas usuarios, con DBFs por un tubo, que las hay, y donde los informáticos están todo el tiempo liados haciendo modificaciones a los programas y dando mantenimiento a los DBFs ?, que ADS les viene a solucionar la vida, porque no tienen tiempo de migrar a nada, o trabajan, o migran y al dueño del negocio le importa un pepino si es ADS, SQL, ADSL o FTP, él lo que quiere es el informe de ventas en su escritorio a fin de mes y ver cuanto ganó o cuanto perdió y lo que haya detrás para llegar a esos resultados poco importa si los datos son reales y confiables, que en el inter contabilidad se haya quedado trabajando hasta las tantas, no importa, que los informáticos han tenido que llegar a las 5 de la madrugada para regenerar indices, tampoco importa lo que importa es el fin, no los medios, que hay mejores medios para llegar al fin, pues si, pero mientras yo tenga resultados, que gire el mundo.

Tengo un caso de un cliente de ADS que tenia una persona de informática única y exclusivamente para "reparar" bases de datos, y no paraba el tío en todo el día, que ya le hablaban de de facturación que los números de factura no eran correctos, venga a regenerar indices, que ahora de contabilidad que el programa ha cascado cuando estaban a medio apunte y claro, no se han actualizado todo los datos, venga a punta de DBU a borrar los datos para que puedan volver a ingresarlos, y ahora que de nómina que a la chica le urgía mirar un dato de un empleado, sin querer le ha dado doble click en el icono de la dbf, ha saltado excel, y claro, como los datos estaban desordenados, pues ¡ hala !, venga a reordenarlos en Excel, y de paso a guardarlos ordenaditos para que la próxima vez no haya problema, vamos, de esas TODOS los dias, solución: meter ADS, implementar la seguridad (de los indices se encarga el servidor) y las transacciones, se acabo el problema.

Tengo otra experiencia con un cliente que tenia 50 usuarios trabajando sobre DBFs con NTX, no te lo pierdas, y claro, como ya eran una empresa "grande", había que jugar como los grandes, y decidieron que Informix era la solución para ellos, pero mientras había que seguir funcionando, así que nos contrataron para una consultoría en implantacion de ADS, pero ojo, ADS era un remedio "temporal" mientras terminaban de implantar Informix, total, ya llevaban invertidos 200 mil dolares en el tema de Informix y por esa pasta Informix tiene que funcionar porque tiene que funcionar, pero mientras pues hay que seguir trabajando, y si con 6 mil dolares puedo hacerlo, pues nada,... ¿ que son esos 6 mil dolares contra los 200 que ya llevo invertido en Informix ? ademas, eso a la larga... uff se va a tirar, si, es caro, pero bueno, me va a permitir seguir trabajando hasta que todo este listo... eso hace 4 años... hoy, la empresa sigue trabajando.... con ADS...

¿Qué pasó? pues nada, que después de 6 meses mas con Informix y otros 100 mil dolares, vieron que a su migración le quedaba para otro añito o así, le dieron las gracias a Informix, y a la fecha siguen trabajando con ADS, es mas, hace como un año me hablaron para actualizar su licencia.

Tengo clientes que después de comprar su primer licencia (que les cuesta lo suyo decidirse) la segunda la compran sin pensarlo, vamos, que una vez que han probado las mieles de ADS, cuando tienen necesidad de un nuevo servidor ya sea para una sucursal o que se han movido y ahora trabajan en otra empresa, les URGE tener ADS.

Y te puedo seguir hablando mas de casos curiosos que tengo con ADS, como por ejemplo aquel cliente que después de 3 años me llama para preguntarme si creo conveniente que haga una regeneración de índices o como aquel que me contactó diciendome que tiene un ADS 4.0 en un Novell 3.11 y que le funciona estupendamente, pero como está por cambiar de servidor a un Windows 2003 (porque Novell sale muy caro) quiere actualizar su ADS a la ultima versión después de 7 años.

Y como han mencionado aquí, tanto Carles como Israel, si sabes como utilizarlo, ADS puede ser tan poderoso como quieras.

Anónimo dijo...

René, excelente tu aporte. Solamente un alcanze. MySQL corre en novell desde el 2001. Tengo uno corriendo sobre un server netware 6.0 desde el 2002 sin parar!!!.
Saludos
David Lagos S.
Coquimbo-Chile