OT: SQL o QUE

[paco-ssi]

Disculpas por el OF Topic, pero tengo una gran duda.
Hasta ahora estoy trabajando con base de datos DBF, y creo que debo cambiar.
Me gustaria saber que me podeis recomendar. SQL, MYSQL, .....
Es importante precio, velocidad, SENCILLEZ, etc
Muchas Gracias por permitirme utilizar vuestro tiempo.
Paco V

[jfgimenez]

Paco,
sinceramente... espera un poco. Dentro de poco haremos un datasource para
ADO. Mi consejo es que si estás acostumbrado a las dbf y no has usando SQL
anteriormente, lo mejor es hacerlo con ADO, que es lo más parecido a las dbf
que puedes encontrar en SQL.
--
Un saludo,
José F. Giménez

[jasm.nospam]

Paco,
SQL es una buena solución. A mi me gusta mas que usar DBF bajo ADS.
En cuanto al motor a usar....
MySQL : Es rápido, sencillo, facil de instalar, configurar y mantener.
Fácil de usar con Eagle 1 (conexion directa al servidor sin usar ODBC,
si no el API del cliente de MySQL). Posibilidad de trabajar con el
sistema embebido, es decir, embutir el servidor en la aplicación para
sistemas monopuesto. Una pega, su no liberas tus programas bajo GNU, GPL
o L-GPL los usuarios tienen que pagar licencia. Si tu aplicación es a
nivel interno de empresa creo que no tiene que pagar, ahora bien, si
distribuyes un programa bajo licencia privativa que se conecta a un
servidor MySQL hay que pagar licencia.
MS SQL Server: Es muy buen motor de bases de datos. Algo complicado de
usar si te metes en grandes complicaciones de bases de datos
(restricciones, procedimientos almacenados, funciones de usuariom, etc).
La pega es que solo está abierto para 5 usuarios concurrentes, lo que
hace que si tienen que conectarse más el precio sea prohibitivo.
Oracle: Excelente. Muy caro. Se vuelve lento con el tiempo.
FireBird: Excelente. Gratuito. Algo complicado de poner en marcha.
Postgres: Excelente. No lo he usado nunca. Gratuita.
Herramientas para usar bases de datos:
- Desde Xailer, con DataControls/DataSets, usando ODBC.
- Eagle 1 para conectar con MySQL. Diversas formas de usarlo. Preguntame
por privado.
- Condor 1 para conectar con cualquier base de datos via ODBC. Muy
rápido y altamente optimizado por Manu Exposito. Soporta todos los tipos
de datos convirtiendolos a formato Clipper/[x]Harbour. Accede
directamente a los cursores de las bases de datos sin necesidad de
apoyarse en arrays locales ni dbf's.
- ADO. Usando ADO a través de OLEDB. Algo engorroso pero muy práctico.
En www.chochurro.com puedes encontrar ejemplos de ADO e Eagle 1.
Un saludo
Jose A. Suarez
PD. NOS VEMOS EN MADRID EL 19 Y 20 DE NOVIEMBRE. INSCRIBETE YA EN
www.olivares2000.org
Paco V escribió:
> Disculpas por el OF Topic, pero tengo una gran duda.
>
> Hasta ahora estoy trabajando con base de datos DBF, y creo que debo cambiar.
>
> Me gustaria saber que me podeis recomendar. SQL, MYSQL, .....
>
> Es importante precio, velocidad, SENCILLEZ, etc
>
> Muchas Gracias por permitirme utilizar vuestro tiempo.
>
> Paco V

[paco-ssi]

Podria conseguir mas información sobre ADO?
Paco V
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:[email=4354e206@ozsrvnegro.ozlan.local...]4354e206@ozsrvnegro.ozlan.local...[/email]
> Paco,
>
> sinceramente... espera un poco. Dentro de poco haremos un datasource para
> ADO. Mi consejo es que si estás acostumbrado a las dbf y no has usando SQL
> anteriormente, lo mejor es hacerlo con ADO, que es lo más parecido a las
> dbf que puedes encontrar en SQL.
>
> --
> Un saludo,
>
> José F. Giménez
>

[jasm.nospam]

Jose,
No tengo nada contra ADO ni contra los datasources, pero siempre me ha
gustado coger por el camino más directo para hacer las cosas. SQL es
SQL, no tiene nada que ver con DBF, ni mucho menos. Son dos cosas
totalmente distintas.
Está bien que se busque la facilidad para hacer las cosas, pero hacer
las cosas fáciles no implica intentar copiar el modelo actual (DBF). Hay
que saber aceptar los cambios y sobre todo si el cambio conlleva gran
parte de identidad propia.
Estamos obcecados con la idea de mantener conexiones permanentes con el
servidor, obtener refrescos de la consulta realizada de forma
instantánea, obligar a la gente a trabajar en el error de que SQL puede
ser usado como DBF, sin preocuparnos de la potencia que ofrecen los
servidores SQL (y la limitación de que se trabaja con datos virtuales en
el cliente).
A diario me llegan mensajes de usuarios acostumbrados a las DBF que usan
las tablas SQL de la misma forma (sea con Eagle 1, o con cualquier otro
sistema de clases), quejandose de que SQL es lento para presentar una
lista de albaranes con el nombre del cliente al lado.... Cuando reviso
el código me doy cuenta de que no saben SQL, eso es culpa de ellos, pero
es culpa nuestra el presentarles las tablas SQL como si de tablas DBF se
tratase para que terminen haciendo un "SELECT *" a la tabla de clientes
por linea del browse para obtener sólo el nombre.
Otra de las cosas que me suelen preguntar es como manejar í­ndices.... En
SQL no son necesarios los í­ndices (excepto el de la clave primaria) ya
que se obtienen las consultas ordenadas desde el servidor. El tema es
que hay gente que se pone a crear í­ndices al estilo DBF (cantidades
exageradas), lo que hace, además, que los procesos de actualización sean
lentos. Bien, es culpa del usuario que no sabe SQL, pero volvemos a lo
mismo, le decimos que con las clases prácticamente no tienen que saber
SQL y ahí­ está nuestro error.
Por otro lado y para terminar, mi forma de trabajar con SQL se basa en
que los datos están en un servidor remoto y que no se debe mantener una
conexión permanente:
- Conectar
- Realizar operacion
- Desconectar
Esa es mi forma de trabajo. Y hasta ahora me va mejor que bien. Sólo hay
que tener en cuenta el hacer el refresco de la consulta actual, bien
sea de forma automática, bien sea de forma manual.
Y no me enrrollo más. Si en Madrid tengo un hueco ya contare más cosas a
los que se interesen.
Saludos,
Jose A. Suarez
Jose F. Gimenez escribió:
> Paco,
>
> sinceramente... espera un poco. Dentro de poco haremos un datasource para
> ADO. Mi consejo es que si estás acostumbrado a las dbf y no has usando SQL
> anteriormente, lo mejor es hacerlo con ADO, que es lo más parecido a las dbf
> que puedes encontrar en SQL.
>

[jfgimenez]

José Alfonso,
no te voy a llevar la contraria en nada de lo que has dicho. Al revés, tú ya
sabes que yo también me encuentro en una situación parecida a la de Paco
Viruete: mis programas están usando dbf y tengo que saltar a SQL.
No obstante, las pruebas que he hecho hasta ahora me han inclinado
definitivamente a usar ADO, pues creo que es la mejor opción y la menos
traumática para pasar de dbf a SQL. Por supuesto que habrá cosas que permite
hacer ADO y que sean una carga excesiva para un servidor y no se deban
hacer, y que haya que cambiar el chip en muchos aspectos, pero aún así mi
apuesta es ADO.
Es más, ni MySQL ni FireBird ni PostgresSQL (por poner algunos) tienen
drivers ADO en condiciones. En cambio, M$ sí los tiene, y muy muy buenos.
Incluso se puede usar ADO a través de ODBC en el caso de que una BD no tenga
drivers ADO, aunque el rendimiento no sea el mejor. Ya tendremos tiempo de
hablar sobre este tema en la reunión del GO2000
--
Un saludo,
José F. Giménez

[jfgimenez]

Paco,
> Podria conseguir mas información sobre ADO?
Todo la documentación está en el Platform SDK de MS y en MSDN. Quizás
también venga bastante en las ayudas de MS-Access.
De todos modos, cuando tengamos implementado el TADODataSource, no creo que
necesites lidiar directamente con ADO.
--
Un saludo,
José F. Giménez

[jose.luis]

José Alfonso,
> No tengo nada contra ADO ni contra los datasources, pero siempre me ha
> gustado coger por el camino más directo para hacer las cosas. SQL es
> SQL, no tiene nada que ver con DBF, ni mucho menos. Son dos cosas
> totalmente distintas.
>
Totalmente de acuerdo. El cambio que supone pasar de las queridas dbf's
a un sistema cliente/servidor con Sql por medio es grande... o muy grande.
> Está bien que se busque la facilidad para hacer las cosas, pero hacer
> las cosas fáciles no implica intentar copiar el modelo actual (DBF). Hay
> que saber aceptar los cambios y sobre todo si el cambio conlleva gran
> parte de identidad propia.
>
Vuelves a tener toda la razón. Por eso tambien existen los Datasources/
Datasets y Datacontrols (entre otras cosas). Este trí­o de instrumentos
no intentan 'emular' el comportamiento de las dbf's. Solo nos muestran
una apariencia similar a como se trabaja con las dbf's. Me explico
mejor. Los Dataxxxx se pueden utilizar como tu quieras. Si quieres
emular las dbf's caes en el peligro de tener una aplicación que puede
llegar a perder agua por muchas partes (y no por cuestión técnica, más
por cuestión de concepto o implementación). Sin embargo, si utilizas
los Dataxxxx de una forma más (vamos a decir) avanzada, estás
acercándote al lí­mite máximo de lo que supondrí­a trabajar directamente
con SQL... solo que el trabajo tedioso de alimentar variables,
controles, etc... te lo hace los Dataxxxxx. Tu, como programador,
puedes (y considero que debes) aprovechar al máximo esas posibilidades
que te ofrece SQL con los Dataxxxxx. Otra cosa distinta es que los
Datasources sean o no eficientes. Ahí­ entramos ya en otra discusión.
> Estamos obcecados con la idea de mantener conexiones permanentes con el
> servidor, obtener refrescos de la consulta realizada de forma
> instantánea, obligar a la gente a trabajar en el error de que SQL puede
> ser usado como DBF, sin preocuparnos de la potencia que ofrecen los
> servidores SQL (y la limitación de que se trabaja con datos virtuales en
> el cliente).
>
Claro.... yo llevo casi 20 años usando dbfs... El cambio no es de hoy
para mañana....
> A diario me llegan mensajes de usuarios acostumbrados a las DBF que usan
> las tablas SQL de la misma forma (sea con Eagle 1, o con cualquier otro
> sistema de clases), quejandose de que SQL es lento para presentar una
> lista de albaranes con el nombre del cliente al lado.... Cuando reviso
> el código me doy cuenta de que no saben SQL, eso es culpa de ellos, pero
> es culpa nuestra el presentarles las tablas SQL como si de tablas DBF se
> tratase para que terminen haciendo un "SELECT *" a la tabla de clientes
> por linea del browse para obtener sólo el nombre.
>
Bueno... es cuestión de ir adaptándose a las 'nuevas tecnologí­as'....
> Otra de las cosas que me suelen preguntar es como manejar í­ndices.... En
> SQL no son necesarios los í­ndices (excepto el de la clave primaria) ya
> que se obtienen las consultas ordenadas desde el servidor. El tema es
> que hay gente que se pone a crear í­ndices al estilo DBF (cantidades
> exageradas), lo que hace, además, que los procesos de actualización sean
> lentos. Bien, es culpa del usuario que no sabe SQL, pero volvemos a lo
> mismo, le decimos que con las clases prácticamente no tienen que saber
> SQL y ahí­ está nuestro error.
>
> Por otro lado y para terminar, mi forma de trabajar con SQL se basa en
> que los datos están en un servidor remoto y que no se debe mantener una
> conexión permanente:
>
> - Conectar
> - Realizar operacion
> - Desconectar
>
Sobre eso, ya discutiremos en la reunión del GO2000 en Madrid... Hay
cosas que pueden ser de una manera o de otra... todo depende de que
tienes detrás y que vas a hacer.
> Esa es mi forma de trabajo. Y hasta ahora me va mejor que bien. Sólo hay
> que tener en cuenta el hacer el refresco de la consulta actual, bien
> sea de forma automática, bien sea de forma manual.
>
> Y no me enrrollo más. Si en Madrid tengo un hueco ya contare más cosas a
> los que se interesen.
>
Ya hablaremos en Madrid...
Saludos,
José Luis Capel

[jose.luis]

José,
>
> no te voy a llevar la contraria en nada de lo que has dicho. Al revés, tú ya
> sabes que yo también me encuentro en una situación parecida a la de Paco
> Viruete: mis programas están usando dbf y tengo que saltar a SQL.
>
> No obstante, las pruebas que he hecho hasta ahora me han inclinado
> definitivamente a usar ADO, pues creo que es la mejor opción y la menos
> traumática para pasar de dbf a SQL. Por supuesto que habrá cosas que permite
> hacer ADO y que sean una carga excesiva para un servidor y no se deban
> hacer, y que haya que cambiar el chip en muchos aspectos, pero aún así­ mi
> apuesta es ADO.
Yo he comenzado una aplicación con Xailer y Sql. AL final hemos optado
por ADO y SqlServer. Creo que ha sido la mejor opción. Puede que no
sea la mejor base de datos (SqlServer), ni la mejor herramienta de
acceso a datos (ADO) pero por la poca experiencia que tengo creo que es
el mejor binomio posible para plataformas Windows a un precio razonable
utilizando xbase (Xailer) como leguaje de programación.
>
> Es más, ni MySQL ni FireBird ni PostgresSQL (por poner algunos) tienen
> drivers ADO en condiciones. En cambio, M$ sí­ los tiene, y muy muy buenos.
> Incluso se puede usar ADO a través de ODBC en el caso de que una BD no tenga
> drivers ADO, aunque el rendimiento no sea el mejor. Ya tendremos tiempo de
> hablar sobre este tema en la reunión del GO2000
>
Realmente crear conectores ADO para otras bases de datos es costoso. Es
por ello que los que hay son betas o simplemente no hay. Además, si
miramos el origen de esas otras bases de datos que has citado, vemos que
o bien vienen del mundo libre o casi... por lo que es, entiendo yo,
difí­cil que se metan en esa labor para dar facilidades al 'lado oscuro'
En fin... en Madrid hablaremos de nuestras experiencias.
Saludos,
José Luis Capel

[ignacio]

José Alfonso,
> Estamos obcecados con la idea de mantener conexiones permanentes con el
> servidor,
Y harás bien, es de lo que más tiempo, CPU y tráfico consume.
>le decimos que con las clases prácticamente no tienen que saber SQL y ahí
>está nuestro error.
Te aseguro que no es así, al menos en el caso de Xailer. Una cosa es la
sentencia de SQL y otra cosa es el manejo del cursor generado por la
sentencia. Creo que no se deben confundir. Es cierto que Xailer pemite hacer
operaciones de altas, bajas y edición directamente sobre DataSets (cursores)
pero son operaciones SQL tremendamente básicas que exigen sin embargo
grandes cantidades de codificación si se hacen a mano. No tiene ningún
sentido hacerlo a mano.
> - Conectar
> - Realizar operacion
> - Desconectar
Una perdida de tiempo innecesaria en mi opinión. Cada día son más
complicados los sistemas de autentificación lo cual implica mayor tráfico de
red y mayor uso de CPU y los servidores SQL cada vez que tienen o pierden
una conexión deben de realizar reasignaciones de memoria. Tanto es así, que
muchas soluciones Middleware ofrecen una cache de conexiones, es decir, se
mantienen 100 conexiones abiertas que se comparten entre todas las
peticiones Web, por ejemplo.
Un saludo,
"Jose Alfonso Suárez Moreno" <jasm.nospam@chochurro.com> escribió en el
mensaje news:43552bf6$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Jose,
>
> No tengo nada contra ADO ni contra los datasources, pero siempre me ha
> gustado coger por el camino más directo para hacer las cosas. SQL es SQL,
> no tiene nada que ver con DBF, ni mucho menos. Son dos cosas totalmente
> distintas.
>
> Está bien que se busque la facilidad para hacer las cosas, pero hacer las
> cosas fáciles no implica intentar copiar el modelo actual (DBF). Hay que
> saber aceptar los cambios y sobre todo si el cambio conlleva gran parte de
> identidad propia.
>
> Estamos obcecados con la idea de mantener conexiones permanentes con el
> servidor, obtener refrescos de la consulta realizada de forma instantánea,
> obligar a la gente a trabajar en el error de que SQL puede ser usado como
> DBF, sin preocuparnos de la potencia que ofrecen los servidores SQL (y la
> limitación de que se trabaja con datos virtuales en el cliente).
>
> A diario me llegan mensajes de usuarios acostumbrados a las DBF que usan
> las tablas SQL de la misma forma (sea con Eagle 1, o con cualquier otro
> sistema de clases), quejandose de que SQL es lento para presentar una
> lista de albaranes con el nombre del cliente al lado.... Cuando reviso el
> código me doy cuenta de que no saben SQL, eso es culpa de ellos, pero es
> culpa nuestra el presentarles las tablas SQL como si de tablas DBF se
> tratase para que terminen haciendo un "SELECT *" a la tabla de clientes
> por linea del browse para obtener sólo el nombre.
>
> Otra de las cosas que me suelen preguntar es como manejar índices.... En
> SQL no son necesarios los índices (excepto el de la clave primaria) ya que
> se obtienen las consultas ordenadas desde el servidor. El tema es que hay
> gente que se pone a crear índices al estilo DBF (cantidades exageradas),
> lo que hace, además, que los procesos de actualización sean lentos. Bien,
> es culpa del usuario que no sabe SQL, pero volvemos a lo mismo, le decimos
> que con las clases prácticamente no tienen que saber SQL y ahí está
> nuestro error.
>
> Por otro lado y para terminar, mi forma de trabajar con SQL se basa en que
> los datos están en un servidor remoto y que no se debe mantener una
> conexión permanente:
>
> - Conectar
> - Realizar operacion
> - Desconectar
>
> Esa es mi forma de trabajo. Y hasta ahora me va mejor que bien. Sólo hay
> que tener en cuenta el hacer el refresco de la consulta actual, bien sea
> de forma automática, bien sea de forma manual.
>
> Y no me enrrollo más. Si en Madrid tengo un hueco ya contare más cosas a
> los que se interesen.
>
> Saludos,
>
> Jose A. Suarez
>
>
> Jose F. Gimenez escribió:
>> Paco,
>>
>> sinceramente... espera un poco. Dentro de poco haremos un datasource para
>> ADO. Mi consejo es que si estás acostumbrado a las dbf y no has usando
>> SQL anteriormente, lo mejor es hacerlo con ADO, que es lo más parecido a
>> las dbf que puedes encontrar en SQL.
>>