BLOG

Más allá de las bases de Datos Relacionales

Por [N4] mperez el | 22 Comments

Velneo, sorprende cuando empiezas a trabajar, pero sorprende mucho más a medida que vas descubriendo las peculiaridades de su base de datos por mucho que hayas trabajado en otros sistemas. Es entonces con el tiempo, cuando recuerdas haber leído que esto realmente era un nuevo paradigma dentro de la programación.

Vamos a mostrar unos pequeños ejemplos para comprobar lo que siempre repetimos en nuestros artículos, blogs y comentarios:

“Si estas empezando y escribiendo procesos de mas de 4 ó 5 líneas, probablemente estés programando a la vieja usanza, gastando horas en balde y complicando tus programas”

Imaginemos una aplicación típica de gestión con las siguientes tablas: Clientes, Artículos (o Rubros), Albaranes (o Remitos), Líneas de Detalle

Supongamos que estamos en un formulario de un cliente y queremos mostrar o saber ¿Qué otros clientes han comprado los mismos artículos que el Cliente en Cuestión?

Si ya pensaste la solución unos minutos, ahora pregúntate:

¿El proceso que estás pensando te llevaría escribirlo más de 6 líneas aunque sea Velneo?

No te preocupes, es normal que tras muchos años en el “Lado Oscuro”, tiendas a escribir líneas y líneas para resolver problemas que desde la lógica de Velneo tienen solución inmediata.

Analicemos de forma real, es decir como pensaríamos si esta operación la tuviéramos que realizar “solo” con nuestra mente. No limites la lógica a los enlaces y herramientas de una base de datos relacional.

¿Que haríamos pensando de forma natural?

1º Buscaríamos todos los albaranes o remitos del cliente y haríamos una lista.
2º Repasaríamos las líneas de detalle y haríamos una nueva lista con todos los artículos que encontramos, sin repetirlos.
3º Partiendo de esa lista de artículos, buscaríamos en todas las líneas de Albaran de todos los clientes, aquellas que contenga alguno de estos artículos
4º Una vez tuviéramos la lista de líneas que contienen estos artículos, obtendríamos todos sus albaranes o remitos a los que pertenecen.
5 º Con ella obtendremos una lista de los clientes en cuestión.

Pues Bien en Velneo sería exactamente lo mismo, partiendo del origen ficha de cliente:

Quizás debas volver a leer el enunciado, para darte cuenta de la complejidad en cualquier otro lenguaje.

Veamos otro caso muy distinto, para darnos cuenta de que Velneo es realmente un nuevo paradigma de la programación.

Imaginemos que tenemos que informatizar un sistema de reserva de alquileres de coches para obtener los vehículos disponibles a una fecha, ante la solicitud de un cliente.

¿Si tenemos que presupuestar el costo en horas de hacer funcionar algo parecido, de cuanto tiempo estamos hablando?, ¿Cuántas líneas de procesos debemos realizar?

Me atrevería a asegurar que no cuesta mas allá de 10 minutos desarrollar esta solución con Velneo.

¿Increíble? No, tan solo utilizar singulares de plural, punteros a hermano y alguna actualización.

Primero esbocemos cual sería nuestra estructura básica de tablas: Vehículos, Clientes, Alquileres y opcionalmente Gamas.

Alquileres tendría un puntero a Maestro al Vehiculo que se reserva y otro al cliente que hace la reserva. Al revés, desde cada uno de ellos una relación a Histórico (Uno a muchos, de un vehiculo o cliente a todos sus alquileres). En el ejemplo aparece el Maestro de Gamas, pero no vamos a hacer ninguna referencia más ya que no es parte esencial del problema.

Alquileres tendría la fecha de entrega y la fecha de devolución entre sus campos necesarios.

 

La tabla de Alquileres necesitará tener el índice: Vehiculo + Fecha de Alquiler.

Con este índice podemos crear inmediatamente un Puntero a Hermano, al siguiente/Anterior alquiler del mismo vehiculo ordenado por fecha.

Por tanto en la tabla de alquileres, podemos crear un campo que sea Días Disponibles, (Día de Entrega del siguiente alquiler – Día de Devolución del que estoy)

Listo, la primera parte resuelta

Ahora nos queda la segunda, de un vehiculo, averiguar si el vehiculo esta disponible o no y mostrar lo que ya resolvimos (¿Cuantos días esta disponible?).

Para eso utilizaríamos un singular de plural. Esta herramienta consiste en apuntar a una reserva del vehiculo de todas las que tiene.

Resumiendo todos los Alquileres de un Vehiculo ordenados por fecha será su Histórico de Alquileres utilizando el índice Alquiler+fecha, será una relación plural, de 1 a muchos.

Por tanto un puntero de Vehículos a uno se sus alquileres, será una relación 1 a 1, a uno de todos, de los plurales.

Eso es lo que significa el puntero “Singular del plural “, con el que apuntar a uno de ellos.

¿En este caso a cual nos interesa? ¿Al primero, al último, a una fecha concreta o a la inmediatamente anterior….?

De todas las posibilidades que hay en este caso elegiremos “Singular del Plural por Índice”. Piensa que no solo jugamos con las posibilidades del puntero, sino también con las múltiples composiciones del índice por la que hacemos la relación uno a muchos.

Un índice del tipo Vehiculo + Importe, resolvería cuestiones completamente distintas.

Un Índice del tipo Vehiculo + Fecha + Hora Entrega, nos haría afinar la solución.

Por tanto tendremos un puntero desde el Vehiculo al alquiler de ese vehiculo inmediatamente anterior a la fecha deseada en cada momento.

Como veis, todo Real. Exactamente resuelto a como lo resolvería nuestra mente.

Creo que me ha costado bastante mas escribirlo que hacerlo.

Seguramente la solución final me obligara a trabajar un poco mas, definir algún campo auxiliar, usar actualizaciones en lugar de campos formula para optimizar, si sabes Velneo comprenderás que esto es cuestión de unos minutos más.

Se me ocurre un ejemplo más, para entender la potencia de esta base de datos.

¿Habéis pensado que un puntero a maestro, puede apuntar sobre la misma tabla?

Lo incomprensible es que esto no lo solucionen ya otras bases de datos, puesto que obedecen a relaciones lógicas y muy comunes en la realidad.

Imaginemos una tabla de socios de un club, en la que un socio trae a otro y así sucesivamente. Por tanto en la tabla de socios, además del campo Código, deberemos tener un nuevo campo que llamaremos Captador. Este campo será un puntero a la misma tabla de socios, ya que apuntara a otro socio.

De esta manera tendremos un puntero sobre la misma tabla Socio-Captador y una relación histórica sobre este mismo índice, resolviendo que socio capto a este y cuantos socios ha captado este y por supuesto incluso de forma recursiva hasta el infinito.

Habremos solucionado un gran problema con un puntero y un enlace a histórico sin necesidad de ninguna solución puente, sin tenernos que preocupar del tema en ninguna parte del programa más.

¿Habéis desarrollado aplicaciones que contengan escandallos complejos?
Si es así sabéis de su dificultad. Basta pensar en el típico caso de un componente “A” que pertenece a un compuesto “B” y este a su vez es componente de un compuesto “C” y así hasta el infinito.

Ahora podemos valorar la potencia que nos pueden dar estos enlaces recursivos sobre la misma tabla, sin necesidad de tablas puente u otros inventos, para resolver lo que las relaciones de Velneo hacen de forma natural.

¿Más ejemplos? Vosotros mismos, tan solo preguntaros, por qué en las soluciones Velneo el stock se lleva a nivel de movimiento evitando recalcular para averiguar las existencias a cualquier fecha o lo mismo en los saldos de contabilidad.

Sencillamente porque la base de datos ya lo resuelve por si misma.

Ahora piensa que las actualizaciones, funcionan sobre todos estos tipos de enlace, estos enlaces son concurrentes y además puedes utilizar toda esta potencia en todos los sitios incluidos Valores Iniciales, Campos Formulas, Procesos, Punteros Indirectos, etc. Además piensa que tienes también punteros indirectos, de los cuales no hemos hablado y que cuesta todavía mas creer que realmente funcionan a la perfección. Parece magia pero no lo es.

Eso si, hay que cambiar el Chip. Piensa en Real.

No te agobies con la potencia de Velneo. Hace poco hablé con un programador que después de 3 años con la herramienta, todavía se asombraba de la potencia del Valor Inicial, sirve para lo más simple y obvio y para lo más inimaginable y complicado, pero eso será otro artículo.

Programar en Velneo es muy rápido, aprovechar toda su potencia, cuestión de años.

Tan solo hay que aplicar lo que una y mil veces nos repitieron en la Facultad, “Todo lo que se pueda definir en Base de Datos, se debe definir en Base de Datos”, la diferencia es que aquí es mucho más.

Velneo es el entorno ágil para el desarrollo
de aplicaciones empresariales

DESCARGAR VELNEO

22 Responses to "Más allá de las bases de Datos Relacionales"
  1. Aztecmexico dice:

    Excelente artículo Miguel, me sirve sobre todo para tener elementos que pueden ser útiles al momento de convencer a un posible cliente de la potencia de la herramienta con la que trabajo, y el consecuente beneficio para sus aplicaciones.

    Saludos.

  2. pfffffff dice:

    Una linea en SQL-Standar

    (SELECT Cliente FROM ALBARAN WHERE CODIGO IN ( SELECT distinct(Alabaran) FROM DETALLE WHERE Articulo in(SELECT Codigo FROM ARTICULO WHERE CODIGO IN (SELECT DISTINCT(Articulo) FROM DETALLE WHERE ALBARAN IN (SELECT Codigo FROM ALBARAN WHERE CLIENTE=x))))

  3. Luis Gonzalez dice:

    Me encanta Pfffff, me ha recordado el sql y me pongo a temblar, es como cuando sueño con los examenes, etapa que ya pase hace mas de 10 años.

    ¿Estara Bien o Estara Mal?, lo releo y tengo mis dudas y son muchos mis años de sql, evidentemente el Sql es muy intuitivo , lenguaje natural. (Para algunos)

    Ahora se me ponen lo pelos de punta si pienso en que en lugar de albaranes son facturas y en que en lugar de Detalle, son lineas o en que quiero solo los articulos de una determinada gama, o simplemente pensar ¿Por que tengo que saber que Articulo, se llama así y no Arti o referencia o lo que sea y que equivocarme en eso implicara que no va nada.

    Solo pensar que una pequeña modificacion en mi estructura de datos me obligase a releer miles del lineas donde pueda aparecer algo de esto o select parecidas, me hace tener escalofrios

    Quizas en este articulo falte comentar algo de que en el proceso de Velneo no tendre que cambiar nada, cambie el nombre de las tablas o los nombres de los campos, siempre funcionara automaticamente ypor supuesto que de un simple vistazo se ve, incluso sin haber escrito una sola linea en Velneo.

  4. pfffffff dice:

    El SQL no es intuitivo en absoluto. Pero es mucho, mucho mas potente que velneo para consultar una base de datos.

    El sistema de Velneo de seleccionar cosas de una lista en vez de escribirlas tambien es una ventaja. Pero en un IDE moderno (VStudio, Eclipse, …) tampoco tanto como era hace un par de años. Generalmente puedes consultar tus tablas en una ventanita, tienes autocompletar y por supuesto, si cambias el nombre de una variable en un lugar te lo lleva a todo el codigo.

    El sistema de guardas los programas en muchos ficheros de texto tiene muchas ventajas: compatibilidad con sistema de gestion de versiones (SourceSafe, CVS,…), facilidad para que varios desarrolladores editen a la vez, generacion simple de patchs y diffs,…

    Velneo te da velocidad de desarrollo (mucha), pero como todo tiene un precio, que no son solo 90 euros.

  5. Borja dice:

    >>El SQL no es intuitivo en absoluto. Pero es mucho, mucho >>mas potente que velneo para consultar una base de datos.

    Efectivamente, no es intuitivo en absoluto. Pero, ¿en qué es más potente para consultar bases de datos?

    >>El sistema de Velneo de seleccionar cosas de una lista en >>vez de escribirlas tambien es una ventaja. Pero en un IDE >>moderno (VStudio, Eclipse, …) tampoco tanto como era >>hace un par de años. Generalmente puedes consultar tus >>tablas en una ventanita, tienes autocompletar y por >>supuesto, si cambias el nombre de una variable en un lugar >>te lo lleva a todo el codigo.

    En Velneo está integrado el IDE con la base de datos, de ahí una de las razones de su potencial. Aquí hablas de completar la base de datos con otra herramienta.

    >>El sistema de guardas los programas en muchos ficheros de >>texto tiene muchas ventajas: compatibilidad con sistema de >>gestion de versiones (SourceSafe, CVS,…), facilidad para >>que varios desarrolladores editen a la vez, generacion simple >>de patchs y diffs,…

    Totalmente de acuerdo. Velneo V7 será maravilloso.

    >>Velneo te da velocidad de desarrollo (mucha), pero como >>todo tiene un precio, que no son solo 90 euros.

    No son 90 euros. Son al igual que otras herramientas y bases de datos, tu tiempo más el precio de las licencias. En Velneo no sólo el precio más accesible, sino que el tiempo de aprendizaje es inferior, y por supuesto el de desarrollo, mantenimiento. Por no hablar de lo rápido que eres productivo, puediendo comercializar tu primer programa en días.

  6. pfffffff dice:

    Obtener las ventas de un cliente:

    SQL – Select Sum(Import) From detall where cliente=x

    Velneo:
    – Set Suma = 0
    – Cargar lista detall , cliente
    – Recorres lista solo lectura
    – Suma = Suma + importe

    O bien generas un acumlado por importe, que puede ser muy util en ciertos casos, pero un desperdicio de recursos y un complicacion inecesaria del codigo en otros.

    SQL es un lenguaje muy potente. Ojo que no hablo de la potencia de la base de datos que este debajo, sino del lenguaje. Lo malo es que es muy dificil.

    Sobre el precio lo que queria decir, es que elegir velneo tiene desventajas:

    No solo la que admites de los ficheros, sino la falta de compatibilidad con el resto, la dificultad para hacer aplicaciones que se salgan del molde, el poco control de los procesos de entrada, la relativa reusabilidad del codigo…

    Lo que no quita que velneo sea una solucion ideal para generar programas de gestion adaptados. Pero no es la panacea universal.

    Y su base de datos no es ninguna evolucion. Es una base de datos relacional, de acuerdo a una definicion matematica de relacional. El resto solo es marketing.

  7. Borja dice:

    En Velneo se utilizaría un campo fórmula de histórico. Se calcularía en tiempo de ejecución igual que la select que comentas. Además, al definirlo a nivel de estructura, lo puedes utilizar para lo que te apetezca. No se, no me parece el mejor ejemplo el que comentas.

    Respecto al precio y a las aplicaciones que se salgan del molde, no se, no te entiendo.

  8. Borja dice:

    Respecto al acumulado, en Velneo se resuelve con actualizaciones, y en ningún momento es un gasto de recursos. Además, al definirlo a nivel de estructura, es muy fácil de mantener por otros.

  9. pffffffff dice:

    Un campo formula historico con muchos historicos, como suelen ser los detalles de los albaranes de un cliente tiene un rendimiento pesimo. Probablemente porque velneo envia todos los datos de los historicos al cliente.

    Y en cuanto al acumulado, cada vez que hagas un alta o modifiques esa ficha, velneo tocara otra, lo que evidentemente afecta al rendimiento. Por supuesto si resulta que el unico acumulado que te interesa es datalle/cliente no seria una mala opcion. Pero como tengas que hacer 5 o 6 acumulados (clientes, articulos, familias, etc..) no solo vas a penalizar el rendimiento, sino que tendras tal lio en la definicion de la tabla que sera mas dificil de mantener que el SQL. Y reza porque un acumulado no toque otra tabla que tenga un acumulado que te produzca un bloqueo.

    Por supuesto he puesto el caso mas sencillo. Ahora complicalo un poquito, como por ejemplo, un caso nada inusual, añade que la consulta la queremos hacer entre fechas. Ya no vale ni la formula historica ni el acumulado.

    Velneo es genial, pero para *consultar* bases de datos SQL es mucho mas potente.

  10. Borja dice:

    No voy a escribir más al respecto.
    Si definir actualizaciones crees que es complicado, me hace pensar que eres un gran conocedor de SQL pero un desarrollador con poca experiencia en Velneo.

  11. pffffff dice:

    Es una pena que dejes de escribir porque la conversacion es interesante ;).

    Tengo 3 o 4 años de experiencia en Velneo, lo que no es demasiado, por supuesto muchos mas con SQL.

    No he dicho que definir actualizaciones sea complicado en ningun lado. He dicho que utilizar muchas actualizaciones complica el mantenimiento del codigo y puede producir problemas de bloqueos.

  12. ADOLFOMONT dice:

    He dedicado largo tiempo, a leer todos los comentarios que se han escrito y me parece que en lugar de contribuir a aclarar ha contribuido a todo lo contrario.

    En mi opinion, el debate sql versus Velneo, es un debate baldío por lo siguientes motivos:

    1º Sql, es simplemente un lenguaje de interrogacion a la base de datos, que nos permite mediante proceso, navegar por estas para averiguar una serie de datos. Por tanto la potencia de Sql esta en funcion de la potencia de enlaces de la base de datos relacional. Velneo (Además de mil cosas más) simplemente hace que esta interrogacion sea mucho más intuitiva. Lo de mas o menos potente, es otra cuestión mucho más discutible, en funcion de lo que cada uno conoce mejor. Por tanto Sql solo se podría comparar con la faceta de Velneo en cuanto a la potencia de las instruciones de Proceso (Cruzar listas, Filtrar, Cargar Maestros e Historicos,etc) y ademas desligandolo de las mayores virtudes de su base de datos y eliminando las funciones que son únicas de este sistema. Pero ciñendonos solo a esta faceta, lo que es obvio , es que es muchisimo mas intuitivo.

  13. ADOLFOMONT dice:

    2º En cuanto a la faceta de Base de datos pura, cualquiera que conozca los funtamentos de una Base de Datos relacional, sabe que en Velneo hay muchos mas conceptos, como bien se explica en el Articulo, Singulares del plural por indice y por posicion, Enlaces Indirectos, o Enlaces a Hermanos (Existentes en otras BD) se salen de lo estrictamente relacional. Eso unido al poder de las actualizaciones, el funcionamiento de los valores iniciales, etc hace de Velneo una Base de Datos muy singular y que el tiempo dira si es mejor o peor y los profesionales de las Universidades decidiran si responde aun nuevo modelo o simplemente a una extension de la Relacional. Para mi y es una opinion tiene conceptos que ya aparecian en otros fundamentos ( Bases de Datos Orientadas a Objetos, orientadas al Comportamiento, Bses de Datos Reticulares, Navegacionales,etc). El resultado esta ahi y espero algún día se documente.De momento a mi como usuario y desarrollador me encanta.

    3º En cuanto a rendimientos, aqui creo que nadie que haya usado Velneo como desarrollador o como programador puede dudar de sus rendimientos. De hecho en el Foro Fran nos habla de sus instalaciones en multinacionales en algun post con servidores en Suecia o Noruega no reecuerdo, cientos de usuarios conectados por todo el mundo y tablas de cientos de millones de registros y por lo que dice Fran, me parece que utiliza muchas actualizaciones, punteros , historicos y otros conceptos que segun pfff! baja el rendimiento. A mi eso me soprende, yo modestamente tambien he usado de todo y mis apliaciones con cientos de milones de rgistros, van como una bala. En fin despues de que alguien nos testimoniara que tenia una tabla con mas de mil millones de registros, funcionaba de maravilla, creo que no puede haber dudas de su incrible rendimiento.

  14. ADOLFOMONT dice:

    4º Creo que de lo que peca en mi opinion el articulo inicial, es comparar con las Bases de Datso reales y la insistencia de que en poco tiempo se programa rápido. Eso es cierto y casi por arte de magia las cosas funcionan, pero entender sus fundamentos y no liarse con ellos, como me parece que le pasa a “Pff!” lleva algo mas de tiempo.

    5º Y finalmente a esto hay que unir que en Velneo todo esta ligado y en la misma base de datos, desde los formularios , hasta la paginas html. Incluso cuando haces un proceso depende de donde lo hagas. Esto puede parecer una limitación , sin embargo para mi es la mayor ventaja. Despreocuparse de tener que controlar en que afecta un cambio en una definicion de datos, ya que todo esta integrado en la base de datos, es una gozada. No se si en el articulo se dice algo de esto, pero definifr una actualizacion , a fin de cuentas es definir una accion o comportamiento en BD. COn lo cual si esta bien, te olvidas de todo y funciona bien siempre, pero quizas requira un esfuerzo de analisis mayor. Si lo llevamos a la exageracion o a lo que sucede cuando empiezas a programar, siempre es mas facil realizar un proceso que filtre una serie de registros que cumplan una condicion, que resolver esto en base de datos. Sin embargo su eficacia , fiabilidad, rendimiento y futuro mantenimiento no tiene comparacion.

  15. ADOLFOMONT dice:

    6º Entiendo que la mayor pega, por lo menos hasta que no nos anuncien lo contrario, es que parte de estas posibilidades, no sea posible atacarlas desde otros sistemas mediante sql, que es el medio universal para esto. Es cierto que a traves de Html, Xml, protocolos tcp, etc esto se minimiza, que es muy dificil, necesitar algo fuera de la herramienta para una solucion, pero en determinadas ocasiones es necesarios y el sql facilitaria la tarea, aunque somos conscientes de que, nunca podriamos mediante este lenguaje aprovechar ni el 50% de la potencia de Velneo, entendemos que como herramienta de comunicacion desde el exterior es necesaria.

  16. pffffffff dice:

    1) La potencia de un lenguaje es la capacidad de este para hacer mas cosas con menos. Si una consulta media en SQL se hace en una linea y en Veleno requiere una busqueda y un proceso de 4 lineas, SQL es mas potente para eso.

    2) Ningun de esos conceptos se sale en absoluto de lo relacional. Todos esos enlaces son tipos “Foreign Keys” en el modelo relacional.

    3) El rendimiento de Velneo es el normal para una base de datos semi-transaccional. Lo que si que es verdad, es que al hacerte programar utilizando indices te obliga a pensar el la optimizacion de las consultas, simplificandola. Pero a no ser que me deis numeros y benchmarks mis impresiones son que tiene un rendimiento normal.

    4) ¿Con que fundamento me he liado? ¿Es que opinar que velneo es el graal de la programacion es un fundamento? ¿Es que todo aquel que no piense que es la solucion definitiva (el 99.99% de los programadores) es que no entienden? ¿Tiene este punto algun interes mas que descalificarme?

    5) En general verdad. Pero es totalmente posible sobreprogramar el “lado izquierdo” y generar aplicaciones dificiles de mantener por eso. Especialmente si la respuesta a todo son las actualizaciones.

    6) ¿Por que desde SQL solo se podria utilizar el 50% de la potencia de Velneo?

  17. Pancho dice:

    La verdad es que después de leer los comentarios de este artículo puedo llegar a entender vuestras posturas. Quizás creo que el problema es que estais tratando de comparar dos cosas que no son comparables (al menos de forma directa).

    Por mi experiencia en el tema, ambos teneis vuestra parte de razón. Por un lado, un lenguaje como SQL, muy versátil y potente, pero que necesita de una base de datos externa para “trabajar” (SQL Server, MySQL, Oracle…).

    Por otro lado, Velneo o Velázquez Visual (como querais llamarle). Una herramienta cuyas mayores ventajas están (yo creo) en la integración total entre base de datos y lenguaje de programación. No se debe tratar como un lenguaje sin más.

    Si comparamos las dos herramientas como lo estais haciendo, estamos tratando a Velneo como un lenguaje de programación única y exclusivamente y creo que no es justo, pues si invierto los papeles y pienso en una aplicación basada en SQL, con base de datos, servidor de aplicaciones, servidor web, servidor de disco… , ahí SQL no sale bien parado, ni técnicamente ni en temas de costes. Y menos en tema de sencillez.

    Desde luego que Velneo no es “la panacea” (nada en este mundo lo es), pero yo si tengo que elegir, me quedo con Velneo.

    Saludos

  18. Pedro dice:

    No quiero entrar en polémica con ningún participante de este blog, así que simplemente hablaré de mi experiencia.

    En mi empresa llevamos más de 20 años desarrollando aplicaciones para mainframes la gran mayoría utilizando SGBD Oracle y DB2, desde hace 5 años desarrollamos aplicaciones con Velázquez Visual, ahora Velneo. Al principio sólo lo utilizábamos para pequeños desarrollos, pero con la aparición del servidor de aplicaciones y tras varios años de experiencia en la actualidad implantamos soluciones basadas en Velázquez en empresas de más de 50 usuarios sin ningún miedo.

    ¿El rendimiento?. Creo que sin necesidad de números y benchmarks, aquel que tenga un cliente con una base de datos de un tamaño considerable (más de 30GB) puede afirmar que Velázquez es capaz de moverla con soltura en un servidor con un sólo procesador y 1 o 2 GB de RAM, algo impensable para una solución basada en Oracle, DB2 o SQL Server. Sobre todo se aprecia ese rendimiento cuando la consulta o búsqueda a realizar cruza múltiples tablas con varios millones de registros, las diferencias en los tiempos de respuesta no dejan lugar a dudas, amén de que el hardware que requieren Oracle o DB2 es muchísmo mayor pero sobre todo (lo que le importa a nuestro cliente) mucho más caro.

    Respecto a sí SQL es más potente que Velázquez, mi opinión es que me resulta cómo usar sentencias SQL cuando me conozco bien las tablas y los campos que intervienen en la sentencia, de no ser así, escribir una sentencia SQL no resulta tan cómoda como escribir carga lista, cargar histórico y recorrer lista eliminando fichas, por ejemplo. Personalmente me resulta más cómodo y seguro escribir instrucciones en un proceso de Velázquez que en una sentencia SQL pues tienes más asistencia y menos riesgo de error.

    Pero por encima de todo lo comentado, lo que más me gusta de Velázquez o Velneo es la tranquilidad que me dan los inspectores, poder pulsar F9 en un campo, saber si no se usa y que puedo borrarlo, o donde se usa. Saber que si cambio un identificador se cambia en todos los objetos que lo utilizan. Por eso cuando tengo que hacer esas tareas sobre Oracle o DB2 me entran sudores, antes de conocer Velázquez no me entraban, jeje, aquí se puede aplicar el dicho de ojos que no ven..

    En fin, que como ya se ha comentado, SQL como tal no se debe comparar con Velázquez, SQL es un lenguaje de consulta de bases de datos relacionales que a finales de los 80 comenzó a implantarse dentro de los lenguajes de programación para el acceso a los datos y Velázquez en una herramienta de programación que engloba la base de datos, la edición y ejecución de programas, servidor de aplicaciones, etc. Lo que sí espero es que en Velneo den algún día la posibilidad de acceder a su base de datos desde aplicativos externos vía ODBC o consulta interactiva SQL, da igual, eso sería importante y nos permitiría tenerla como una opción económica frente a Oracle o DB2 en muchas instalaciones.

    Salu2.

  19. XAVIER dice:

    eSTOY LEYENDO HACERCE DEL PROGRAMA Y ME INTERESA MUCHO CONOCER ESTE NUEVO ENTORNO YA Q DESARROLLO APLICACIONES PARA PIMES.. PERO TAMBIEN ME INTERESAN LOS COSTOS DE LINCENCIAS..

  20. JUAM MANUEL JUAMA@ dice:

    QUISIERA SABER SOBRE LA TABLA MERCADERIAS Y COMO HACER PARA LA COMPOSICION DE LOS ARTICULOS ..GRACIAS

  21. rqvargas dice:

    Hola a todos:

    He leído las innumerables discrepancias entre desarrolladores de uno y otro(s) bandos y me parece que cada quien tiene su justa razón por lo cual defienden uno u otro lenguaje o aplicación.

    Tengo una aplicación que quisiera rehacer, pero antes de eso quiero ponerme en los zapatos del consumidor final, aquel cliente que usa mi aplicación y cuyos datos puede explotar sin pagar ninguna licencia de ningún tipo, simplemente pago la aplicación y todo lo que necesita esta incluido en el precio. Me refiero a los datos que se encuentran almacenados en un archivo binario.

    Si emigro a Velneo y rehago la aplicación, mi cliente necesitará pagar por la B.D. o esta está incluida en la aplicación (programación)?

    Gracias por sus innumerables debates.

  22. MARTIN dice:

    BUENO… ESTOY CURSANDO EL CUARTO AÑO DE ING EN SISTEMAS EN UNA UNIVERSIDAD DE ARGENTINA X… e dado un paseo por los diferentes lenguajes y paradigmas de la programacion, y realmente este producto (velneo) atribuye a una de mis grandes ambiciones y es la de poder independisarme con mi propio grupo de programadores creo que se hace posible gracias a ella…
    de velneo no conosco mucho pero apunta a un futuro tecnologico inevitable “unificar”… los lenguajes cambian, las metodologias cambian y cuanto menor tiempo en adaptarce mejor para reducir todos los costos involucrados…
    siempre y ha sido una tendencia economica-practica se ha tratado de reducir la cantidad de personal de una empresa (desgraciadamente) y esta tambien es una tendencia de este tren al que creo debemos subirnos…
    Tecnicamente y logicamente esta herramienta deberia tener compatibilidad con distintos lenguajes y motores de bases de datos para abrirle las puertas a otras tecnologias y tendencias que tambien crecen como lo son las de acceso y control remoto que pronto y creanme van a ser parte indispensable de una aplicación para el control online de la misma…
    yo soy un fanatico del paquete c++-builder-sql que logicamente son mas potentes que un paquete velneo y con muchas mas limitaciones… ahora necesito realmente velocidad luz para las bd de 5000 usuarios con las que trabajo o bien 10000000 de usuarios….
    bueno… saludos a todos … y mis felicitaciones por los conocimientos…

Deja un comentario

Esta web utiliza cookies. Si continúa navegando acepta dichas cookies y nuestra política de cookies. Gracias. ACEPTAR

Aviso de cookies