To puede desarrollar en velneo pero utilizar una base de datos diferente, como oracol, mysql, etc
Esta entre las ideas propuestas, si tienes posibilidad de votar, aprovecha:
http://ideas.velneo.es/forums/61867-ideas/suggestions/1385231-desarrollar-directamente-sobre-bases-de-datos-exte
un saludo
José Luis
http://www.ascsl.com
@cristianvg2003.gmail
Creo que la idea no debería ser "esto no es Velneo", porque Velneo SA no creo que tenga esa política de cerrarse al mundo, menos aun en el Siglo XXI y viendo como evoluciona la informática.
.
Desde la 6X a la v7, hay muchas buenas iniciativas de Velneo por ponerse a tono con los tiempos, por eso apunta a la nube, por eso es multiplataforma, incluyendo Android, y ahora se trabaja con QML, XML y Javascript. Aun falta atacar la REALIDAD AUMENTADA, en mi opinión, que es lo ++ actualmente.
.
Eso si, incluso en la V7 empieza su apertura hacia BD externas, aunque aun no permite el desarrollo nativo sobre ellas.
.
Aparte de la idea sobre BD externas (que ya llegó a primera página!!), en este hilo se mencionan mas cosas: http://velneo.es/foros/topic/conectar-v7-con-sql
.
Yo creo que buena parte de lo necesario ya está hecho (el acceso actual a BD externas desde V7, via procesos), seguro falta mapear mas cosas y encapsularlas mejor, para tener los primeros objetos ODBC básicos (rejillaODBC, formularioODBC, InformeODBC) que ayudarían al menos a salvar las papas en esos casos, y no dejaría de ser un gran primer paso, sin necesidad de obstaculizar la funcionalidad actual de Velneo v7.
Hola,
@cjribera, ojala que tengas razón ... pero tu vez por algún lado que Velneo SA tenga intenciones de realizar ese tipo de integraciones ?, yo personalmente no lo veo ni cerca en el roadmap, no me voy a meter en los "debe ser" sino en lo que es a hoy y lo que se ve venir, por lo menos este año.
ojala, la verda ojala, pero yo no me haría ilusiones, como indico en el post, en mi opinion personal de lo que alcanzo a apreciar en los movimientos y filosofía de Velneo no veo las intenciones la verdad.
Saludos,
@cristianvg2003, yo te repondía por lo de la frase "que no es Velneo", creo que sería conformismo aceptar eso sin intentar al menos postular la idea.
.
No niego que actualmente no esté entre las prioridades del roadmap, sino que digo que no deberíamos resignarnos tan fácil, como usuarios.
.
Yo creo que como usuarios, si algún poder de voto nos han dado, es menester nuestro al menos usarlo, para que por lo menos vean que hay interés en la comunidad, independientemente si lo meten al roadmap o no.
.
Si la comunidad no muestra interés, pues las posibilidades se achicarán aun mas, porque los que mas reacios están a aceptar esa limitación, suelen ser usuarios nuevos que están evaluando Velneo, pero esos no pueden votar.
No creo que Velneo se abra para permitir el desarrollo sobre bases de datos externas porque precisamente ese es parte de su negocio, la venta de las licencias de los vServer Estandard y Enterprise (o Professional). Es mas que obvio que si permite esto, dejaría de vender algunas de estas licencias.
Ahora, la otra dificultad que tal vez tengan para permitir esto, es la integración que hay entre proyecto de datos y de aplicación; solo la base de datos de Velneo te permite crear los tipos de indices y busquedas conforme ella lo hace y poder luego aprovechar las ventajas que ofrece su utilización en el proyecto de aplicación. Surgen entonces preguntas como estas:
¿Cómo se haría un cargar plurales sobre una DB externa?
¿Cómo cargar un maestro del plural?
¿Cómo moverse al hermano contiguo?
¿Cómo armar una busqueda con diferentes componentes?
Y muchas mas que de momento no alcanzo a dimensionar.
Yo por mi parte pienso que Velneo debería analizar, que si se abre a esta idea es posible que pierda parte del mercado de los vServers, pero tal vez eso se pueda recuperar con la llegada de más desarrolladores que adquirirían las licencias de los diferentes niveles que ellos ofrecen.
Solo quería compartir con ustedes mi opinión sobre esto, pues también soy de los que piensan que para Velneo sería mas provechoso implementar esta idea y si resulta ser muy complicado que nos los haga saber.
Cordial Saludo.
YIMY MORA ACONCHA
Hola blanyi
¿Cómo se haría un cargar plurales sobre una DB externa?
¿Cómo cargar un maestro del plural?
¿Cómo moverse al hermano contiguo?
¿Cómo armar una busqueda con diferentes componentes?
http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_4/ManualPracticoSQL.pdf
Un saludo. Roberto Blasco.
Hola Roberto Blasco.
Yo creo que la mayoría de los que estamos en esto conocemos las sentencias SQL, lo que yo quiero decir es como poder dar unas ordenes a una base de datos externas para que produzcan el mismo resultado que se obtiene usando tablas, indices, búsquedas nativos de Velneo.
Conforme a la arquitectura de Velneo ellos ya tienen unas sentencias nativas o propias para trabajar sobre su base de datos propietaria. Me imagino que para lograr lo mismo sobre una DB externa tendrían que hacer un gran trabajo para que para nosotros sea transparente el asunto, es decir que para nosotros sea lo mismo lanzar una orden si lo hacemos sobre la db de Velno que si lo hacemos para una db Mysql, Orcale, Postgre, SQL Server, etc,
Espero haber aclarado mi punto de vista.
YIMY MORA ACONCHA
Hola blanyi
Todo pasa (y creo que ya hay algo de eso publicado por el vArquitecto) en poner el origen de datos de una rejilla como un objeto. A partir de ahí cómo se alimente, con SQL o con procesos nativos de Velneo que sea la decisión del usuario.
A lo que quería decir con el comentario anterior es que todo eso que comentas de los punteros y relaciones de Velneo ya existe en SQL pero con otros nombres ...
Un saludo. Roberto Blasco.
@Roberto Blasco exacto, probablemente todas (no conozco a fondo Velneo como para decir todo con 100% de certeza) las operaciones que sugiere blanyi, ya tienen una consulta SQL equivalente.
.
De hecho yo mismo hago esto con Netbeans, cuando construyo una interfaz de usuario y por debajo le pongo sentencias SQL para ejecutar las consultas que se han hecho en la GUI, sin que el usuario tenga idea de que existe algo llamado SQL.
.
Ademas, con los objetos hipotéticos RejillaODBC, FormularioODBC e InformeODBC, apegandosé a un estándar ANSI SQL, no se necesitará un trabajo adicional por cada RDBMS que haya que acceder. Es algo básico, pero ya salvaría las papas y serviría como punto de partida.
.
Encima no afectaría en nada a los objetos actuales Velneo, pues serían objetos nuevos, que no tendrían nada que ver con la 'Rejilla' (o Superrejilla cuando salga), 'Formulario' e 'Informe' actuales de Velneo, eso parece no haber sido completamente comprendido.
Ok, siendo las cosas como lo plantea cjribera.yahoo y Roberto Blasco entonces la razón por la cual no se ha implementado el desarrollo sobre DB externa no es técnica, pues podrían, entonces, encapsularse sentencias SQL estandard que podríamos usar como cualquier otra orden de Velneo, utilizando tanto para las entradas como para las salidas los nuevos objetos hipoteticos aquí propuestos.
¿Cuál es la razón entonces por la cual Velneo se resiste abrirse a esta idea?
YIMY MORA ACONCHA
Muchos conocen los componentes de la coca-cola, pero ninguna a logrado reproducirla porque no conocen las medidas exactas de cada componente, ni los tiempos de preparación.
Muchos aquí saben o sabemos qué tecnologías o plataformas son utilizadas para desarrollar V7, pero no sabemos realmente como están implementadas, desde mi punto de vista es un error el suponer que es demasiado sencillo hacer tal o cual implementación de nuevas funcionalidades, igual y es demasiado difícil, eso solo lo saben el vArquitecto y su equipo de desarrollo.
No sé cual sea la razón, ni me interesa, de porqué no han decidido tomar ciertos caminos, aún así apuesto todo por la plataforma.
Algunos prospectos de clientes comentan que no se quieren casar con nada y cuando les hago ver que están CASADOS con ciertas tecnologías (y con las rémoras que las acompañan) y sin convenio prenupcial con sus BD actuales y que eso les pega directamente en el bolsillo, les cambia el color del rostro.
Si todo lo que se puede hacer en la BD de Velneo se puede hacer en las demás BD pues no veo la razón de existir de Velneo, pero le doy el beneficio de la duda, sobre todo después de ver y sufrir en carne propia como las "otras", las "grandes" azotan, caen y tumban aplicaciones porque una consulta SQL las tumba como si nada, después de tener que cuidar al máximo la cantidad de índices que puede "manejar óptimamente" un sistema basado en una de las grandes BD, después de tener que andar haciendo circo maroma y teatro porque hay que "particionar" las tablas para que no se caiga la BD y mejore su rendimiento, después de pagar miles de dólares (y de dolores) por asesorías de empresas certificadas por los creadores de las BD para hacer tunning a las mismas y obtener un mínimo de mejoría, y así un largo, larguísimo etc.
Quizá V7 no lo vaya a tener nunca porque Velneo nos quiere ahorrar todos esos problemas, o quizá lo hace porque no quiere generar un nuevo mercado de "especialistas" en tunear su BD para que mejore su rendimiento después de que unas cuantas e inofensivas consultas SQL la tiran, "...y eso es responsabilidad de quien desarrolla, diseña, implementa, decide...." dirán algunos, y quizá tengan razón, pero los únicos que deciden para donde jala esta carreta son dos y todos los conocemos y algunos hasta los admiramos, y si esos dos deciden qué ponen y qué no ponen, por el criterio que ellos mismos eligen (sea técnico o comercial) pues simple, si la plataforma me sirve, la uso, si no pues busco otras opciones.
Si quienes dirigen esto aciertan, pues me va a ir muy bien, si se equivocan y V7 se va al carajo, pues le voy a batallar un tiempo, hasta que encuentre otro Velázquez Visual y el ciclo inicie de nuevo.
La respuesta puntual para la pregunta inicial a este hilo, NO se puede. y agregando un poco y quizas de manera un tanto temeraria diría: y NO se va a poder cuando menos en el corto/mediano plazo. Si por las razones que sea, dentro de algún tiempo el vArquitecto se inventa un vSQL y lo implementa pues que bueno, si no lo hace pues también que bueno, que al cabo que V7 tiene sus propios medios para hacer las cosas.
Como diría Galileo después estar con la Inquisición, ".....Si, no tiene SQL y no se puede desarrollar directo sobre otras BD, y no puede utilizar eclipse para editar, y estos de Velneo son bien cerrados y no hacen caso.....................................y sin embargo es MEJOR que muchas otras (y come muchísimos menos recursos, y una o dos personas se hacen cargo de todo)".
Un saludo.
Martin Ibarra.
@Martin Ibarra Cuando dices: "La respuesta puntual para la pregunta inicial a este hilo, NO se puede..... y agregando un poco y quizas de manera un tanto temeraria diría: y NO se va a poder cuando menos en el corto/mediano plazo"
Quisiera preguntarte si tomas en cuenta esto: http://velneo.es/comandos-de-conexion-con-bases-de-datos-externas/
.
Es decir, viste que Velneo no está en cero en cuanto a BD externas?
.
Sobre lo demás que dices, tendré que reiterar conceptos vertidos en otro hilo. No se trata de que digamos que Oracle o PostGreSQL sean mejor BD que Velneo.
.
De lo que se trata es de, poder tomar clientes QUE YA TIENEN UNA BD FUNCIONANDO. Imagínate una transnacional, una empresa pública, una petrolera, minera o un banco. Son instituciones grandes, donde encontrar una organización asi, que no tenga una BD funcionando (por muchos años, para mas inri), es la excepción y no la regla.
.
Pues he aquí, que ese tipo de organización requiere un desarrollo vertical específico, donde en algunos casos, deberás operar directamente sobre la BD (form, rejilla, informe o búsqueda sobre tablas existentes y con datos).
.
Aun suponiendo que fuera cierto y demostrable que Velneo supera a los demas RDBMS, tu, como desarrollador, no les puedes decir "tiren su Oracle a la basura y usaremos ahorar VelneoDB, que es superior, e implementaremos la BD desde cero."
.
¿Cual crees que sería la reacción de tu pre cliente? Te daría el trabajo, o se lo daría a otra empresa, que pueda desarrollarles la relativamente pequeña aplicación vertical directamente sobre la BD que ya tienen, sin necesidad de reimplementar la BD desde cero?
.
Otro ejemplo, un cliente tiene una BD con elementos geográficos, aun si el cliente aceptara tirar su BD a la basura y usar Velneo, ¿como se almacenarian los datos geográficos, de forma nativa? Esta funcionalidad no tiene Velneo: http://postgis.refractions.net/
.
Y lo de las geo referencias, ya no vale solo para los grandes sistemas geográficos de antaño, pues con la REALIDAD AUMENTADA, la capacidad de almacenar información geo referenciada será cada vez mas OBLIGATORIA que opcional.
.
Vean esto, los 'google glasses' que usaran Android como SO
O en este video se entiende mejor la importancia de la geo referencia dentro de la realidad aumentada.
.
En resumen, ya sea para poder tomar trabajos de clientes que ya tienen una BD y no van a reemplazarla, o para poder usar características geográficas que la BD Velneo no tiene aun, se necesita poder desarrollar sobre BD externas.
.
Espero haberme explicado mejor ahora, el porque la importancia de desarrollar sobre BD externas.
.
No digo que debamos obligar a Velneo a esto o aquello, solo trato de alertar la importancia del tema, con el objetivo de ser competitivos como desarrolladores de cara a las nuevas tendencias que son una realidad ya existente, o muy próxima.
.
Saludos.
Buen día a todos,
cjribera, la verdad me confundes, por un lado comentas una cosa y por el otro otra, tú mismo te contradices, en tu primer post de este hilo citas lo siguiente:
.
Eso si, incluso en la V7 empieza su apertura hacia BD externas, aunque aun no permite el desarrollo nativo sobre ellas.
.
Por eso mi punto, actualmente no se puede y reitero, no creo que en el corto/mediano plazo se pueda. Otro punto es que podamos acceder a otras BD para explotar la información en ellas contenida, o para mandar igualmente información hacia ellas.
Respecto a los demás puntos que mencionas, tienes razón, así son las cosas y así seguirán siendo, claro que con sus excepciones, como la de que (y principalmente) en el Gobierno si pueden cambiar de BD de un proyecto a otro o su misma evolución, ya que cuando se licita la continuidad o evolución de un proyecto, por ley (cuando menos en México) no pueden obligar a los licitantes a proponer una cierta BD, ¿Qué hacen entonces?, pues tambien contratan la migración de datos y BD, con todo el lio que eso implica. Digo, no en valde Oracle, Microsoft e IBM se la pasan tumbando de un proyecto a otro las BD de la competencia, quiza eso sea parte del negocio.
Hay empresas que desarrollan con V7 que han ido atacando ese tipo de proyectos, y los han resuelto satisfactoriamente para sus clientes, que no lo comenten abiertamente en los foros no quiere decir que no tengan la experiencia en las soluciones para ese tipo de problemas, solo cuando hablas con ellos te das cuenta que el problema es menor de lo que aparenta ser (o mayor, depende de nuestros conocimientos al respecto). Hay quienes te asesoran al respecto con sus experiencias, hay quienes cobran (es parte del negocio) por la consultoría, y tambien hay quienes lo hacen y se lo guardan para ellos solos, ya que de momento lo ven como una ventaja competitiva para su negocio, y todas estas opciones son válidas, todo depende el modelo de negocio de cada empresa o desarrollador.
Los temas al respecto son bastante amplios y los puntos de vista y experiencias son aún mayores y en muchos casos totalmente opuestos unos de otros, creo que eso es bastante enriquecedor para todos, aprender en cabeza ajena, lo bueno y lo malo.
Independientemente de nuestros puntos de vista, en ocasiones coincidentes y en otras opuestos parcial o totalmente, te agradezco infinitamente tus participaciones en el foro, ya que en más de una ocasión me han puesto a caminar el hamster.
Un saludo.
Martin Ibarra.
@Martin Ibarra, no entiendo lo de la posible contradicción, porque una cosa es 'empezar una apertura hacia BD externas' (si comparas lo que había en la 6X, con V7, entenderás de que se trata) y otra muy distinta el poder ya desarrollar una aplicación vertical sobre una BD existente, sin necesidad de cambiar la BD.
.
Ahora, lo de las empresas que han atacado este tipo de proyecto me gustaría saber detalles, aunque como dices, esa información no siempre quieren publicarla o al menos comentarla.
.
Según mi experiencia, en informática todo se puede, y en estos proyectos, con replicación, sincronización (mas uso de otras herramientas como complemento) y cosas así, podrias salir adelante. Pero el punto es que si compras una herramienta como Velneo, la idea es justamente evitar tener tanta programación de medio y bajo nivel (que es lo que hay que hacer en esos casos) para poder concentrarse en las reglas del negocio del cliente.
.
Por lo menos como lo veo ahora, creo que con Velneo, se complicaría mas que con Eclipse (o Netbeans, mas xCode para una versión iOS limitada en cuanto a alcance) atacar un proyecto asi (por poner un ejemplo posible: BD externa ya existente, datos georeferenciados (puntos, líneas, polígonos), funcionalidad de realidad aumentada, accesible en algunos módulos desde iOS y Android), quizá me equivoque y haya opciones con Velneo que desconozca, que me permitan hacer algo mas que lo que yo entiendo que se debería hacer para solucionar un proyecto de este estilo. De todas maneras, aun estoy investigando opciones.
Por si acaso, me olvidaba, Velneo no debería tener porque perder dinero con el acceso a BD externas. Esa funcionalidad se va a necesitar generalmente para proyectos grandes, donde el costo de los vServers es perfectamente asumible.
El vServer mismo puede seguir montorieando la funcionalidad de Velneo y la concurrencia a la aplicación, por mucho que sea a otra BD lo que se accede.