El futuro del acceso a las bases de datos

On Fri, 15 Apr 2005 09:20:54 +0200, "Octavio Hernandez"
wrote:

Pues básicamente se conoce como "impedance mismatch" (no sabría ni como
traducirlo bien)

Desadaptación de impedancia.

al "agujero" de distancia que separa la programación de
aplicaciones (hoy principalmente basada en la POO) y la programación para
bases de datos (basada en SQL y la teoría relacional).

Y con esta solución el "agujero" desaparece limpiamente. Las tablas de
la base de datos pasan a ser ciudadanos de primera clase en C#, es
decir van a ser como variables normales y corrientes y SQL se
convierte en un subconjunto de C#.

Con esto los DataSets de ADO.NET dejan de tener sentido, ya no hace
falta cargar tablas en memoria, manipularlas usando código
procedimental y enviar el resultado de nuevo a la base de datos.
Podemos trabajar directamente con las tablas de la base de datos como
si fuesen variables normales y corrientes, que de hecho lo son.

Se va a acabar eso de tener que escribir el código SQL entre comillas,
las consultas relacionales hechas en la aplicacion van a tener la
misma verificación de tipos en tiempo de compilación que el resto del
código. Las clases de negocio dejarán de tener cualquier sentido.

COmega está dando sus primeros pasos y aun se puede mejorar mucho.
También deberían incluir soporte para crear tablas no persistentes
totalmente ajenas a la base de datos, es decir que además de poder
crear "arrays" podamos crear tablas temporales que pertenezcan a la
aplicación con la misma facilidad.


Saludos

Aquí hay algo más sobre el tema:

http://en.wikipedia.org/wiki/Impedance_mismatch

Saludos,

Jose Luis Manners, MCP
English: http://blogs.geekdojo.net/jmanners
Español: http://weblogs.golemproject.com/jmanners/

"Encuentra felicidad en tu trabajo o nunca serás feliz."
Cristóbal Colón


"Octavio Hernandez" wrote in message
news:

Pues básicamente se conoce como "impedance mismatch" (no sabría ni como
traducirlo bien) al "agujero" de distancia que separa la programación de
aplicaciones (hoy principalmente basada en la POO) y la programación para
bases de datos (basada en SQL y la teoría relacional).

Slds,

Octavio

escribió en el mensaje
news:0f9901c54184$64098080$
Para los no versados, en qué consiste específicamente ese
problema ?


>
>¡Por fin alguien está resolviendo el problema
del "impedance mismatch"
>de la forma correcta!
>
>Mirad esto:
>
>http://research.microsoft.com/Comeg..._tutorials
_sqlquery.htm
>
>
>Saludos
>.
>

Y también, de hecho,esto ya es parte de la versión 3.0 de
C#.

Saludos

Miguel Ortiz Falcón

Sorry... entiendo cual es la idea... mas no entiendo cual es la facilidad.
Si quieres tener un lenguaje orientado a DATOS, para eso tienes VFOX, creo
que anda acorde con lo que deseas.
Sobre lo de olvidarte de escribir SQL entre comillas y todo ese rollo, entra
otra salvedad, que puede convertirse en una dificultad, la diferencia de
sintaxis de SQL que existen entre las distintas bases de datos.
Creo que es un tema muy amplio, pero vamos a ver por donde va la cosa. Yo
por mientras no me hago problemas con los lenguajes de programacion, porque
al fin al cabo es cuestion de acostumbrarse a como lo usas y lo mejoras.

Salu2

Victor Rafael Bocanegra Arias
Lima, Peru


"Alfredo Novoa" escribió en el mensaje
news:

On Fri, 15 Apr 2005 09:20:54 +0200, "Octavio Hernandez"
wrote:

Pues básicamente se conoce como "impedance mismatch" (no sabría ni como
traducirlo bien)

Desadaptación de impedancia.

al "agujero" de distancia que separa la programación de
aplicaciones (hoy principalmente basada en la POO) y la programación para
bases de datos (basada en SQL y la teoría relacional).

Y con esta solución el "agujero" desaparece limpiamente. Las tablas de
la base de datos pasan a ser ciudadanos de primera clase en C#, es
decir van a ser como variables normales y corrientes y SQL se
convierte en un subconjunto de C#.

Con esto los DataSets de ADO.NET dejan de tener sentido, ya no hace
falta cargar tablas en memoria, manipularlas usando código
procedimental y enviar el resultado de nuevo a la base de datos.
Podemos trabajar directamente con las tablas de la base de datos como
si fuesen variables normales y corrientes, que de hecho lo son.

Se va a acabar eso de tener que escribir el código SQL entre comillas,
las consultas relacionales hechas en la aplicacion van a tener la
misma verificación de tipos en tiempo de compilación que el resto del
código. Las clases de negocio dejarán de tener cualquier sentido.

COmega está dando sus primeros pasos y aun se puede mejorar mucho.
También deberían incluir soporte para crear tablas no persistentes
totalmente ajenas a la base de datos, es decir que además de poder
crear "arrays" podamos crear tablas temporales que pertenezcan a la
aplicación con la misma facilidad.


Saludos

On Fri, 22 Apr 2005 08:54:44 -0500, "Víctor Rafael Bocanegra Arias"
wrote:

Si quieres tener un lenguaje orientado a DATOS, para eso tienes VFOX, creo
que anda acorde con lo que deseas.

No, no tiene nada que ver. Lo que deseo es la integración de las
estructuras de datos relacionales en los lenguajes de programación de
aplicaciones, y Visual Fox no hace eso nada bien.

Sobre lo de olvidarte de escribir SQL entre comillas y todo ese rollo, entra
otra salvedad, que puede convertirse en una dificultad, la diferencia de
sintaxis de SQL que existen entre las distintas bases de datos.

Eso es un asunto del compilador que debería traducir el dialecto SQL
de COmega (que tampoco es SQL estandar) al dialecto del SGBD.

En realidad esa es otra gran ventaja de COmega. Las aplicaciones van a
poder cambiar mucho más fácilmente de SGBD, si es que Microsoft
implementa soporte para varios SGBD.

Creo que es un tema muy amplio, pero vamos a ver por donde va la cosa. Yo
por mientras no me hago problemas con los lenguajes de programacion, porque
al fin al cabo es cuestion de acostumbrarse a como lo usas y lo mejoras.

No es solo cuestión de acostumbrarse, es cuestión de productividad. La
productividad en el desarrollo de aplicaciones de bases de datos con
las herramientas actuales es muy baja y COmega supone una mejora
importante, aunque todavía queda mucho por hacer.


Saludos