In order for this site to work correctly we need to store a small file (called a cookie) on your computer. Most every site in the world does this, however since the 25th of May 2011, by law we have to get your permission first. Please abandon the forum if you disagree.

Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.

MySql

SQL databases
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 10:51 am

Tengo que empezar a enterarme algo de SQL. Creo que empezare con MySql por
sus innumerables ventajas. (Sobre todo Precio).
Pregunto:
Lo que haga en MySql valdra para otros SQL? Mi empresa trabaja con SQL
Server.
Voy a comenzar por instalar MySql.
Os voy a dar bastante la lata. Gracias por aguantarme.
Paco V
antonio.ortega
Posts: 124
Joined: Wed May 17, 2006 10:50 am

MySql

Postby antonio.ortega » Sat Sep 30, 2006 11:03 am

Paco, tambien tienes la opción de MS SQL Server Express 2005, que es mas o
menos lo mismo que MS SQL Server 2005 , pero con algunas limitaciones, es
totalmente gratuito y redistribuible, información en la red hay por millon,
tienes los libros en pantalla de microsoft, viene con un administrador, y
con base de datos de ejemplos, es facil de instalar, creo que con fines
didacticos y porque no comerciales viene muy pero que muy bien, ten en
cuenta que puedes pasar de SQL Express a la SQL 2005 en forma transparente.
Un Saludo.
Antonio F. Ortega
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 11:25 am

Ya empiezan mis dudas.
Antonio: Mi Ingles no llega mas que para decir Oui, y supongo que este
vendra en riguroso Inglis.
Mi idea seria conseguir un ABM de datos. Programa instalado en un ordenador
que hace de servidor y al que se conectan otros para ejecutar el ABM. Los
datos y la aplicación me interesa que esten en el servidor.
Como lo ves?.
Paco V
"Antonio F. Ortega" <antonio.ortega@ono.com> escribió en el mensaje
news:451e32c5$1@news.xailer.com...
> Paco, tambien tienes la opción de MS SQL Server Express 2005, que es mas o
> menos lo mismo que MS SQL Server 2005 , pero con algunas limitaciones, es
> totalmente gratuito y redistribuible, información en la red hay por
> millon, tienes los libros en pantalla de microsoft, viene con un
> administrador, y con base de datos de ejemplos, es facil de instalar, creo
> que con fines didacticos y porque no comerciales viene muy pero que muy
> bien, ten en cuenta que puedes pasar de SQL Express a la SQL 2005 en forma
> transparente.
>
> Un Saludo.
>
> Antonio F. Ortega
>
antonio.ortega
Posts: 124
Joined: Wed May 17, 2006 10:50 am

MySql

Postby antonio.ortega » Sat Sep 30, 2006 12:01 pm

"ba a se que no", la documentacion tambien está español, lo cual es bastante
bueno, y hay foros en español, y paginas web en
español.......y...y.y........... Por cierto ya hay que olvidarse del tópico
que todo está en inglés, los hispanoparlantes somos muchos millones. :-)
Lo que tu quieres es un ejecutable que 'ataque' a un servidor de base de
datos , primero deberás instalar el servidor de base de datos en el
ordenador que tu quieras, y luego el programa realizado por ti , el cual
deberá "conectarse" al servidor de base de datos, y a partir de esto ya
puedes crear tu base de datos, añadir datos y realizar las operaciones
comunes , el programa se conecta por tcp/ip (en la mayoria de los casos),
ten en cuenta que SQL Express solo correrá en SO Windows, no en Linux, en
ese aspecto MySQL es más flexible, ya que corre en "cualquier" SO.
Puedes mirar los ejemplos de Xailer, para ver como "ataca" (conexion ODBC)
un programa a una base de datos, mediante lenguaje SQL., ( ODBCData1,
ODBCData2, ODBCData3 ), tambien hay ejemplos en el blog de Capel, pero ya
usando otra forma de "atacar" (conexion ADO).
En mi opinion, y como diria un viejo amigo, hay que cambiar el chip, y para
hay que ir poco a poco, porque la forma de programar cambia, lo que antes,
con DBF's, se hacía "instintivamente" ahora hay que pensarlo y hay varias
formas de hacerlo.
Antonio F. Ortega
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 12:14 pm

Antonio, entonces lo primero que debo hacer es instalar MySql en el portatil
que utilizo para programar.
Instalar el servidor de base de datos en el mismo portatil.
Crear una tabla y empezar.
Despues con cambiar, digamos, el apuntador al servidor de datos real
bastaria?
Paco V
"Antonio F. Ortega" <antonio.ortega@ono.com> escribió en el mensaje
news:451e4074$1@news.xailer.com...
> "ba a se que no", la documentacion tambien está español, lo cual es
> bastante bueno, y hay foros en español, y paginas web en
> español.......y...y.y........... Por cierto ya hay que olvidarse del
> tópico que todo está en inglés, los hispanoparlantes somos muchos
> millones. :-)
>
> Lo que tu quieres es un ejecutable que 'ataque' a un servidor de base de
> datos , primero deberás instalar el servidor de base de datos en el
> ordenador que tu quieras, y luego el programa realizado por ti , el cual
> deberá "conectarse" al servidor de base de datos, y a partir de esto ya
> puedes crear tu base de datos, añadir datos y realizar las operaciones
> comunes , el programa se conecta por tcp/ip (en la mayoria de los casos),
> ten en cuenta que SQL Express solo correrá en SO Windows, no en Linux, en
> ese aspecto MySQL es más flexible, ya que corre en "cualquier" SO.
>
> Puedes mirar los ejemplos de Xailer, para ver como "ataca" (conexion ODBC)
> un programa a una base de datos, mediante lenguaje SQL., ( ODBCData1,
> ODBCData2, ODBCData3 ), tambien hay ejemplos en el blog de Capel, pero ya
> usando otra forma de "atacar" (conexion ADO).
>
> En mi opinion, y como diria un viejo amigo, hay que cambiar el chip, y
> para hay que ir poco a poco, porque la forma de programar cambia, lo que
> antes, con DBF's, se hacía "instintivamente" ahora hay que pensarlo y hay
> varias formas de hacerlo.
>
> Antonio F. Ortega
>
>
>
User avatar
ignacio
Site Admin
Posts: 8691
Joined: Mon Apr 06, 2015 8:00 pm
Location: Madrid, Spain
Contact:

MySql

Postby ignacio » Sat Sep 30, 2006 12:33 pm

Antonio,
>>tambien hay ejemplos en el blog de Capel, pero ya usando otra forma de
>>"atacar" (conexion ADO).
La próxima versión de Xailer incluirá soporte de ADO. De hecho ya está
terminado y funcionando.
No obstante saldrá publicado como versión Beta por si hubiera que hacer
algún cambio importante dentro del código que pudiera afectar al código
fuente de algún usuario.
Además del nuevo DataSource TADODataSource se incluyen dos nuevos DataSets
que van a ser auténticos camaleones: TSQLQuery y TSQLTable. Ambos datasets
están preparados no sólo para funcionar con ADO, sino con cualquier otro
DataSource tipo SQL que desarrollemos en el futuro. Soporte de SQLLite o
MYSQL, por ejemplo.
De esta forma, cambiar de motor de base de datos en una aplicación, si va
ser efectivamente un trabajo sencillísimo. En lo que se refiere a la
aplicación sólo habrá que cambiar el DataSource, eso es todo.
El hecho de que salga el soporte ADO en versión beta es sencillamente por
los posibles problemas que nos podamos encontrar en la incorporación de
nuevos DataSources que puedan obligarnos a cambiar levemente la estructura
de los nuevos Datasets TSQLQuery y TSQLTable y ello pueda afectar al code
fuente de algún usuario.
Un saludo,
Ignacio Ortiz de Zúñiga
[Equipo de Xailer / Xailer team]
http://www.xailer.com
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 12:40 pm

Ignacio:
Entonces para los que no tenemos NPI, merece la pena esperar ese poquito que
va a tardar en salir la Nueva Versión?
Paco V
"Ignacio Ortiz de Zúñiga" <NoName@xailer.com> escribió en el mensaje
news:451e480b$1@news.xailer.com...
> Antonio,
>
>>>tambien hay ejemplos en el blog de Capel, pero ya usando otra forma de
>>>"atacar" (conexion ADO).
>
> La próxima versión de Xailer incluirá soporte de ADO. De hecho ya está
> terminado y funcionando.
>
> No obstante saldrá publicado como versión Beta por si hubiera que hacer
> algún cambio importante dentro del código que pudiera afectar al código
> fuente de algún usuario.
>
> Además del nuevo DataSource TADODataSource se incluyen dos nuevos DataSets
> que van a ser auténticos camaleones: TSQLQuery y TSQLTable. Ambos datasets
> están preparados no sólo para funcionar con ADO, sino con cualquier otro
> DataSource tipo SQL que desarrollemos en el futuro. Soporte de SQLLite o
> MYSQL, por ejemplo.
>
> De esta forma, cambiar de motor de base de datos en una aplicación, si va
> ser efectivamente un trabajo sencillísimo. En lo que se refiere a la
> aplicación sólo habrá que cambiar el DataSource, eso es todo.
>
> El hecho de que salga el soporte ADO en versión beta es sencillamente por
> los posibles problemas que nos podamos encontrar en la incorporación de
> nuevos DataSources que puedan obligarnos a cambiar levemente la estructura
> de los nuevos Datasets TSQLQuery y TSQLTable y ello pueda afectar al code
> fuente de algún usuario.
>
> Un saludo,
>
>
antonio.ortega
Posts: 124
Joined: Wed May 17, 2006 10:50 am

MySql

Postby antonio.ortega » Sat Sep 30, 2006 12:55 pm

Gracias Ignacio, la verdad es que es una muy buena noticia, espero que
pronto tengamos la version beta disponible.
Paco, ADO es una Sistema de Acceso a Datos, mas moderno que ODBC, aunque
ODBC continua usandose, si vale la pena esperarse....creo que si.
Antonio F. Ortega
antonio.ortega
Posts: 124
Joined: Wed May 17, 2006 10:50 am

MySql

Postby antonio.ortega » Sat Sep 30, 2006 12:56 pm

Exactamente, yo en el portatil, tengo MySQL, SQL Server 2005 Express, y
tenia FireBird. Los servidores de base de datos, se instalan como servicio y
puedes tener varios instalados y corriendo al mismo tiempo.
Antonio F. Ortega
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 12:59 pm

Muchas Gracias.
Creo que esperare, aunque ya empiezo a tener la necesidad.
Paco V
"Antonio F. Ortega" <antonio.ortega@ono.com> escribió en el mensaje
news:451e4d06$1@news.xailer.com...
> Gracias Ignacio, la verdad es que es una muy buena noticia, espero que
> pronto tengamos la version beta disponible.
>
> Paco, ADO es una Sistema de Acceso a Datos, mas moderno que ODBC, aunque
> ODBC continua usandose, si vale la pena esperarse....creo que si.
>
> Antonio F. Ortega
>
antonio.ortega
Posts: 124
Joined: Wed May 17, 2006 10:50 am

MySql

Postby antonio.ortega » Sat Sep 30, 2006 1:13 pm

Paco, quizás el primer paso ( y no soy quien para aconsejar ) sea instalarte
el servidor y una herramienta de Administracion ( Navicat , MySQL-Front
ambos para MySQL, o SQL Server Management Studio Express CTP par MS SQL
Express ) , a partir de esto puedes practicar a crear base de datos, tablas
y consultas, en mi opinión , con esto conseguirias fluidez en el lenguaje
SQL, lo cual lleva su tiempo, el tiempo necesario quizas para que ya
tengamos Xailer-ADO :-)
Antonio F. Ortega
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 1:21 pm

Antonio, tu te la has buscado. Te voy a hacer caso al pie de la letra.
Hoy mismo voy a instalar MySql en el portatil y creo que tengo MySql Control
Center que creo que es una herramienta para creal tablas.
Gracias de Nuevo.
Paco V
"Antonio F. Ortega" <antonio.ortega@ono.com> escribió en el mensaje
news:451e5176$1@news.xailer.com...
> Paco, quizás el primer paso ( y no soy quien para aconsejar ) sea
> instalarte el servidor y una herramienta de Administracion ( Navicat ,
> MySQL-Front ambos para MySQL, o SQL Server Management Studio Express CTP
> par MS SQL Express ) , a partir de esto puedes practicar a crear base de
> datos, tablas y consultas, en mi opinión , con esto conseguirias fluidez
> en el lenguaje SQL, lo cual lleva su tiempo, el tiempo necesario quizas
> para que ya tengamos Xailer-ADO :-)
>
> Antonio F. Ortega
>
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Sat Sep 30, 2006 2:26 pm

También está Eagle1 :-)
Lo puedes ver en: http://es.groups.yahoo.com/group/eagle1/
Saludos
Antonio F. Ortega escribió:
> "ba a se que no", la documentacion tambien está español, lo cual es bastante
> bueno, y hay foros en español, y paginas web en
> español.......y...y.y........... Por cierto ya hay que olvidarse del tópico
> que todo está en inglés, los hispanoparlantes somos muchos millones. :-)
>
> Lo que tu quieres es un ejecutable que 'ataque' a un servidor de base de
> datos , primero deberás instalar el servidor de base de datos en el
> ordenador que tu quieras, y luego el programa realizado por ti , el cual
> deberá "conectarse" al servidor de base de datos, y a partir de esto ya
> puedes crear tu base de datos, añadir datos y realizar las operaciones
> comunes , el programa se conecta por tcp/ip (en la mayoria de los casos),
> ten en cuenta que SQL Express solo correrá en SO Windows, no en Linux, en
> ese aspecto MySQL es más flexible, ya que corre en "cualquier" SO.
>
> Puedes mirar los ejemplos de Xailer, para ver como "ataca" (conexion ODBC)
> un programa a una base de datos, mediante lenguaje SQL., ( ODBCData1,
> ODBCData2, ODBCData3 ), tambien hay ejemplos en el blog de Capel, pero ya
> usando otra forma de "atacar" (conexion ADO).
>
> En mi opinion, y como diria un viejo amigo, hay que cambiar el chip, y para
> hay que ir poco a poco, porque la forma de programar cambia, lo que antes,
> con DBF's, se hací­a "instintivamente" ahora hay que pensarlo y hay varias
> formas de hacerlo.
>
> Antonio F. Ortega
>
>
>
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Sat Sep 30, 2006 5:49 pm

Hola Paco,
>
> Pregunto:
> Lo que haga en MySql valdra para otros SQL? Mi empresa trabaja con SQL
> Server.
>
Te voy a responder desde la perspectiva que me está dando mi corta
expierencia en el mundo cliente/servidor y bases de datos.
Yo he llegado a la conclusión de que programar pensando en varios sistemas
de bases de datos es algo no recomendable desde un punto de vista pŕactico
y económico.
Pero antes de decirte el porqué, deberás decidir sobre cual sistema de
acceso a tus datos vas a basarte. Como estamos en un foro de Xailer me
imagino que es éste el GUI sobre el que trabajas. Para Xailer tienes, de
forma nativa, los datasources. Actualmente solo hay uno que te pueda ser
de interés: odbc. No obstante, como ya ha apuntado Ignacio, en breve vas a
terner acceso a datos a través de ADO. Fuera de Xailer, existe Condor1 (de
Manu Expósito). No te cito Eagle 1 por que está especializado en MySql. Si
me dejo alguno... lo siento.
Desde mi punto de vista creo que ADO es una decisión acertada. Te permite
utilizar la misma jerarquí­a de clases para todos los orí­genes de datos
aceptados. Y ADO acepta prácticamente toooodos los sistemas de bases de
datos, bien a través de un proveedor nativo OleDb, bien a través de odbc.
Una vez has elegido tu sistema de acceso a datos, deberás elegir muy bien tu
sistema de bases de datos. Ambos dos (acceos y datos) deberán estar muy
bien 'compenetrados'. Si este binomio tiene algún problema tu aplicación
puede que tambien la tenga.
Y volviendo al principio... ¿por que solo un sistema en vez de pensar en
todos? Bueno... mi teorí­a personal es la siguiente. Empezamos diciendo que
todo depende del cliente al que va orientado tus aplicaciones. Si piensas
que para un cliente, por costes, le vendes el sistema con dbf's y, si el
cliente te dice que tiene tal base de datos y no quiere ponerse otra,
entonces vas a tener que hacer lo siguiente. Por una parte vas a tener que
aprender (como mí­nimo) las diferencias que hay en cada uno de los
fabricantes de bases de datos. Estas diferencias pueden ser sutilezas o
cambios radicales en la funcionalidad. Además vas a tener que aprender a
administrar tantas bases de datos diferentes como integres en tu
aplicación. Por lo tanto, deberás de aprender todas las herramientas de
administración de cada sistema (el nivel de profundidad de conocimiento lo
pones tu y tus necesidades). Además vas a tener que formar al personal de
soporte en las diferentes problemáticas de la aplicación según esté
utilizando una u otra base de datos.
Pero esto serí­a fácil si no fuera por que al programar deberás decidir por
cual camino tiras. Si por el mí­nimo común múltiplo o el máximo común
divisor ;-)
Es decir, si pretendens mantener tu programa (me refiero a fuentes) de tal
manera que el el mismo código sea útil para todos los sistemas te obliga de
cierta manera a tener que bajar el nivel de productividad y eficiencia de
tus sistema de datos dado que no vas a poder utilizar las técnicas
avanzadas por que justamente suele ser esa parte la más incompatible entre
los diferentes BD.
Si por el contrario decides sacar el máximo provecho a cada sistema de bd
entonces deberás especializar tu código. Esto te supone tener prg
diferente por cada uno de los sistemas. Poco vas a poder tener en común.
En ambos casos el coste de mantenimiento va a ser alto.
Por ese motivo yo, perosnalmente, pienso que lo mejor es decidir un sistema
de base de datos y aprovechar al 100x100 sus capacidades.
Bueno... espero que no os haya aburrido con tanta literatura.
Saludos,
José Luis Capel
paco-ssi
Posts: 390
Joined: Mon Feb 07, 2005 4:17 pm

MySql

Postby paco-ssi » Sat Sep 30, 2006 6:13 pm

Jose Luis:
Efectivamente, trabajo con Xailer. Ahora tengo una aplicación en la que
utilizo Dbf con los dataset. Realmente gracias a Xailer he conseguido poener
en marcha una aplicación para Windows con muy pocos problemas. Seguramente
en muchos sitios este haciendo cosas mal, pero funciona.
El problema que tengo es que los datos y la aplicacion engordan, con lo que
el sistema se hace cada vez un poco mas lento. A eso añado que se conectan
desde diferentes ciudades a la aplicación, con lo que todavia se hace mas
lento.
A base de chapuzas he conseguido que no se note tanto la lentitud, pero
estar está.
El dilema lo encuentro en decidir por donde tiro.
Si tiro por MySql no hace falta invertir y puedo ir probando y aprendiendo,
y ademas parece que Xailer lo va a hacer poco complicado.
Ademas si en algún momento hago algo para un cliente particular creo que
tambien valdria.
A lo mejor estoy equivocado, pero no creo que si en algún momento tengo que
cambiar a SQL Server, el cambio no seria muy traumatico. Al menos bastante
menos que el quiero comenzar ahora.
Dame tu opinión, creo que habra alguien mas con este dilema.
Muchas Gracias
Paco V
"José Luis Capel" <jose.luis@capelsoft.com> escribió en el mensaje
news:451e921b@news.xailer.com...
> Hola Paco,
>
>>
>> Pregunto:
>> Lo que haga en MySql valdra para otros SQL? Mi empresa trabaja con SQL
>> Server.
>>
>
> Te voy a responder desde la perspectiva que me está dando mi corta
> expierencia en el mundo cliente/servidor y bases de datos.
>
> Yo he llegado a la conclusión de que programar pensando en varios sistemas
> de bases de datos es algo no recomendable desde un punto de vista practico
> y económico.
>
> Pero antes de decirte el porqué, deberás decidir sobre cual sistema de
> acceso a tus datos vas a basarte. Como estamos en un foro de Xailer me
> imagino que es éste el GUI sobre el que trabajas. Para Xailer tienes, de
> forma nativa, los datasources. Actualmente solo hay uno que te pueda ser
> de interés: odbc. No obstante, como ya ha apuntado Ignacio, en breve vas
> a
> terner acceso a datos a través de ADO. Fuera de Xailer, existe Condor1
> (de
> Manu Expósito). No te cito Eagle 1 por que está especializado en MySql.
> Si
> me dejo alguno... lo siento.
>
> Desde mi punto de vista creo que ADO es una decisión acertada. Te permite
> utilizar la misma jerarquía de clases para todos los orígenes de datos
> aceptados. Y ADO acepta prácticamente toooodos los sistemas de bases de
> datos, bien a través de un proveedor nativo OleDb, bien a través de odbc.
>
> Una vez has elegido tu sistema de acceso a datos, deberás elegir muy bien
> tu
> sistema de bases de datos. Ambos dos (acceos y datos) deberán estar muy
> bien 'compenetrados'. Si este binomio tiene algún problema tu aplicación
> puede que tambien la tenga.
>
> Y volviendo al principio... ¿por que solo un sistema en vez de pensar en
> todos? Bueno... mi teoría personal es la siguiente. Empezamos diciendo
> que
> todo depende del cliente al que va orientado tus aplicaciones. Si piensas
> que para un cliente, por costes, le vendes el sistema con dbf's y, si el
> cliente te dice que tiene tal base de datos y no quiere ponerse otra,
> entonces vas a tener que hacer lo siguiente. Por una parte vas a tener
> que
> aprender (como mínimo) las diferencias que hay en cada uno de los
> fabricantes de bases de datos. Estas diferencias pueden ser sutilezas o
> cambios radicales en la funcionalidad. Además vas a tener que aprender a
> administrar tantas bases de datos diferentes como integres en tu
> aplicación. Por lo tanto, deberás de aprender todas las herramientas de
> administración de cada sistema (el nivel de profundidad de conocimiento lo
> pones tu y tus necesidades). Además vas a tener que formar al personal de
> soporte en las diferentes problemáticas de la aplicación según esté
> utilizando una u otra base de datos.
>
> Pero esto sería fácil si no fuera por que al programar deberás decidir por
> cual camino tiras. Si por el mínimo común múltiplo o el máximo común
> divisor ;-)
>
> Es decir, si pretendens mantener tu programa (me refiero a fuentes) de tal
> manera que el el mismo código sea útil para todos los sistemas te obliga
> de
> cierta manera a tener que bajar el nivel de productividad y eficiencia de
> tus sistema de datos dado que no vas a poder utilizar las técnicas
> avanzadas por que justamente suele ser esa parte la más incompatible entre
> los diferentes BD.
>
> Si por el contrario decides sacar el máximo provecho a cada sistema de bd
> entonces deberás especializar tu código. Esto te supone tener prg
> diferente por cada uno de los sistemas. Poco vas a poder tener en común.
>
> En ambos casos el coste de mantenimiento va a ser alto.
>
> Por ese motivo yo, perosnalmente, pienso que lo mejor es decidir un
> sistema
> de base de datos y aprovechar al 100x100 sus capacidades.
>
> Bueno... espero que no os haya aburrido con tanta literatura.
>
> Saludos,
> José Luis Capel
>
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Sat Sep 30, 2006 7:39 pm

Paco,
> El dilema lo encuentro en decidir por donde tiro.
> Si tiro por MySql no hace falta invertir y puedo ir probando y
> aprendiendo, y ademas parece que Xailer lo va a hacer poco complicado.
> Ademas si en algún momento hago algo para un cliente particular creo que
> tambien valdria.
Ambas dos son soluciones acertadas.
>
> A lo mejor estoy equivocado, pero no creo que si en algún momento tengo
> que cambiar a SQL Server, el cambio no seria muy traumatico. Al menos
> bastante menos que el quiero comenzar ahora.
>
Puede que para cosas sencillas el cambio no será traumático. No obstante si
empiezas a profundizar en una base de datos, el cambio puede no ser tan
sencillo.
> Dame tu opinión, creo que habra alguien mas con este dilema.
>
La elección de la base de datos es tuya. Solo puedo decirte que con
SqlServer estoy muy contento. Tambien he de decirte que no he probado
MySql al mismo nivel que SqlServer...
Saludos,
José Luis Capel
User avatar
jfgimenez
Site Admin
Posts: 5629
Joined: Mon Apr 06, 2015 8:48 pm
Contact:

MySql

Postby jfgimenez » Sat Sep 30, 2006 7:56 pm

José Luis,
> Si por el contrario decides sacar el máximo provecho a cada sistema de bd
> entonces deberás especializar tu código. Esto te supone tener prg
> diferente por cada uno de los sistemas. Poco vas a poder tener en común.
Seguramente yo no soy el más indicado para opinar en este punto, dada mi
falta de experiencia, pero me voy a atrever a hacerlo...
Yo no creo que sea tan drástico como dices. Vamos a ver, si no me equivoco,
habrá básicamente 3 tipos de sentencias SQL que vamos a utilizar en
cualquier programa:
- Sentencias de actualización de datos (INSERT y UPDATE): no creo que haya
diferencias significativas entre unos motores y otros. Además, si se utiliza
un sistema de acceso a datos como ADO, entonces ni siquiera vamos a usar
estas sentencias.
- Sentencias de carga de datos en los mantenimientos (p.ej. cargar en un
array las líneas de un pedido): no creo que sea necesario utilizar
sentencias SELECT tan complicadas que sean incompatibles entre distintas
BB.DD.
- Consultas para informes, extractos, etc.: aquí sí creo que puede haber
diferencias entre distintos motores. Pero como ya comentamos este verano,
creo que este problema se puede resolver creando vistas en la BD y entonces
desde el programa nos limitaremos a poner "SELECT * FROM VistaLoQueSea"
salvando las incompatibilidades.
Respecto a los lenguajes de manipulación de la BD (crear la BD, usuarios,
tablas, etc.) sí es cierto que todos son distintos. Pero hoy dia te coges
cualquier programa de administración de la BD y te genera un script completo
que puedes guardar en un campo memo de un dbf, y tener en ese dbf varios
registros, uno por cada BD que soporte tu programa.
Puede que haya otras características que diferencien las distintas BB.DD. y
que puedan influir puntualmente en el diseño de un programa, pero
francamente creo que con un poco de imaginación se pueden solucionar y no
ser un escollo para poder soportar, no digo todas, pero sí 2 ó 3 BB.DD. en
un programa sin complicarse la existencia.
--
Un saludo,
José F. Giménez
http://www.xailer.com
José F. Giménez
[Equipo de Xailer / Xailer team]
http://www.xailer.com
http://www.xailer.info
User avatar
jfgimenez
Site Admin
Posts: 5629
Joined: Mon Apr 06, 2015 8:48 pm
Contact:

MySql

Postby jfgimenez » Sat Sep 30, 2006 7:57 pm

Paco,
> A lo mejor estoy equivocado, pero no creo que si en algún momento tengo
> que cambiar a SQL Server, el cambio no seria muy traumatico. Al menos
> bastante menos que el quiero comenzar ahora.
Como acabo de decir, no tengo suficiente experiencia en SQL, pero sí estoy
completamente seguro de que el salto de DBF a SQL siempre es mucho más
grande que el de un motor SQL a otro.
--
Un saludo,
José F. Giménez
http://www.xailer.com
José F. Giménez
[Equipo de Xailer / Xailer team]
http://www.xailer.com
http://www.xailer.info
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Sat Sep 30, 2006 8:27 pm

José,
Almacenamientos almacenados, disparadores, DML, DDL... muchas cosas a tener
en cuenta. Desde mi punto de vista hay muchas cosas que hace que si quieres
sacarle al máximo el partido a una base de datos te tengas que
especializar. Todo lo demás es generar código para compatiblizar dos o más
sistemas cuando, a lo mejor, estás instalando un 70% de uno y un 30% del
resto, mientras mantienes la misma proporción en tiempo de mantenimiento de
cada sistema. Algo que, enconómicamente no acabo de comprender. Pero como
he dicho, es solo mi opinión.
Saludos,
José Luis Capel
Jose F. Gimenez wrote:
> José Luis,
>
>> Si por el contrario decides sacar el máximo provecho a cada sistema de
>> bd
>> entonces deberás especializar tu código. Esto te supone tener prg
>> diferente por cada uno de los sistemas. Poco vas a poder tener en
>> común.
>
> Seguramente yo no soy el más indicado para opinar en este punto, dada mi
> falta de experiencia, pero me voy a atrever a hacerlo...
>
> Yo no creo que sea tan drástico como dices. Vamos a ver, si no me
> equivoco, habrá básicamente 3 tipos de sentencias SQL que vamos a
> utilizar en cualquier programa:
>
> - Sentencias de actualización de datos (INSERT y UPDATE): no creo que
> haya diferencias significativas entre unos motores y otros. Además, si se
> utiliza un sistema de acceso a datos como ADO, entonces ni siquiera vamos
> a usar estas sentencias.
>
> - Sentencias de carga de datos en los mantenimientos (p.ej. cargar en un
> array las líneas de un pedido): no creo que sea necesario utilizar
> sentencias SELECT tan complicadas que sean incompatibles entre distintas
> BB.DD.
>
> - Consultas para informes, extractos, etc.: aquí sí creo que puede haber
> diferencias entre distintos motores. Pero como ya comentamos este verano,
> creo que este problema se puede resolver creando vistas en la BD y
> entonces desde el programa nos limitaremos a poner "SELECT * FROM
> VistaLoQueSea" salvando las incompatibilidades.
>
> Respecto a los lenguajes de manipulación de la BD (crear la BD, usuarios,
> tablas, etc.) sí es cierto que todos son distintos. Pero hoy dia te coges
> cualquier programa de administración de la BD y te genera un script
> completo que puedes guardar en un campo memo de un dbf, y tener en ese dbf
> varios registros, uno por cada BD que soporte tu programa.
>
> Puede que haya otras características que diferencien las distintas BB.DD.
> y que puedan influir puntualmente en el diseño de un programa, pero
> francamente creo que con un poco de imaginación se pueden solucionar y no
> ser un escollo para poder soportar, no digo todas, pero sí 2 ó 3 BB.DD.
> en un programa sin complicarse la existencia.
>
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Sat Sep 30, 2006 8:54 pm

José,
>
> - Sentencias de actualización de datos (INSERT y UPDATE): no creo que
> haya diferencias significativas entre unos motores y otros. Además, si se
> utiliza un sistema de acceso a datos como ADO, entonces ni siquiera vamos
> a usar estas sentencias.
El que uses ADO no significa que renuncies a utilizar DML. Yo estoy
utilizando uno y otro dependiendo de la situación. De hecho utilizar
directamente DDL es mucho más rápido que con ADO. Aparte lo anterior, los
insert y updates se pueden complicar mucho. Puedes hacer sentencias update
como esta
UPDATE supplier
SET supplier_name = ( SELECT customer.name
FROM customers
WHERE customers.customer_id = supplier.supplier_id)
WHERE EXISTS
( SELECT customer.name
FROM customers
WHERE customers.customer_id = supplier.supplier_id);
Con lo cual puede que uno u otro sistema no sea sitácticamente igual.
>
> - Sentencias de carga de datos en los mantenimientos (p.ej. cargar en un
> array las líneas de un pedido): no creo que sea necesario utilizar
> sentencias SELECT tan complicadas que sean incompatibles entre distintas
> BB.DD.
>
Bueno... depende... todo depende de lo que quieras buscar y como lo quieras
traer. Yo utilizo select sencillas y otras donde hago una ristra de inner
joins de varios niveles.
> - Consultas para informes, extractos, etc.: aquí sí creo que puede haber
> diferencias entre distintos motores. Pero como ya comentamos este verano,
> creo que este problema se puede resolver creando vistas en la BD y
> entonces desde el programa nos limitaremos a poner "SELECT * FROM
> VistaLoQueSea" salvando las incompatibilidades.
>
Las vistas pueden ser una solución válida...
> Respecto a los lenguajes de manipulación de la BD (crear la BD, usuarios,
> tablas, etc.) sí es cierto que todos son distintos. Pero hoy dia te coges
> cualquier programa de administración de la BD y te genera un script
> completo que puedes guardar en un campo memo de un dbf, y tener en ese dbf
> varios registros, uno por cada BD que soporte tu programa.
>
Entonces tienes que aprender varios programas de administración de datos.
Tambien has de aprender la sintáxis de cada uno para saber que campos y
tipos crear. Aparte está de disparadores y esas cosillas...
> Puede que haya otras características que diferencien las distintas BB.DD.
> y que puedan influir puntualmente en el diseño de un programa, pero
> francamente creo que con un poco de imaginación se pueden solucionar y no
> ser un escollo para poder soportar, no digo todas, pero sí 2 ó 3 BB.DD.
> en un programa sin complicarse la existencia.
>
Con imaginación puedes solventar muchos escollos. Estoy seguro de ello.
Pero imaginar cuesta tiempo... y además luego has de acordarte de lo
imaginado para sueño por que si no... puede llegar a ser una pesadilla
(José, permí­teme este juego de palabras sin ánimo de ofender ni nada por el
estilo).
Saludos,
José Luis Capel
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Sun Oct 01, 2006 10:42 am

Creo que los dos tenéis razón, como siempre...
Desgraciadamente el estandar sólo tiene unas especificaciones básicas y
cada proveedor amplí­a con creces a ese estanadar creando
incompatibilidades. Realmente eso nunca ha sido lo importante para los
fabricantes de bases de datos, por desgracia.
En SQL, me refiero en bases de datos relacionales, lo importante a tener
en cuenta son las tres capas básicas y la ubicación de estas.
- Las reglas de integridad y coherencia, estarí­an indiscutiblemente en
el gestor de bases de datos...
- Las reglas de negocio, aquí­ si habrí­a dudas ya que estas podrí­an estar
en la Base de datos o en el programa de acceso. Precisamente lo que se
intenta es que los datos sean lo más independientes posible del programa
que los accede. Deberí­amos conseguir que lo de menos fuera el programa
que los accede que podrí­a ser Delphi, VB o Xailer por ejemplo. Hay que
recordar que hacer un cálculo de una nómina, por ejemplo será mucho más
facil y rápido hacerlo en el servidor con un Procedimiento almacenado
que en un programa PRG en el cliente...
- Programa que accede a los datos. Aquí­ cada uno elegirá el que más le
guste, yo Xailer, jeje.
Pienso que los programadores deberí­amos llegar a usar las sentencias SQL
directamente ya que las podrí­amos adaptar al gestor de bases de datos
que usemos...
Y se quiera o no un cambio en la Base de Datos significa un cambio en
programas a pesar del uso de DataSet o Datasources...
Ahora no puedo seguir, me voy con mis niños a la calle, pero si sigue el
hilo seguiré con la exposición...
Saludos
José Luis Capel escribió:
> José,
>
>> - Sentencias de actualizaci�n de datos (INSERT y UPDATE): no creo que
>> haya diferencias significativas entre unos motores y otros. Adem�s, si se
>> utiliza un sistema de acceso a datos como ADO, entonces ni siquiera vamos
>> a usar estas sentencias.
>
> El que uses ADO no significa que renuncies a utilizar DML. Yo estoy
> utilizando uno y otro dependiendo de la situación. De hecho utilizar
> directamente DDL es mucho más rápido que con ADO. Aparte lo anterior, los
> insert y updates se pueden complicar mucho. Puedes hacer sentencias update
> como esta
>
> UPDATE supplier
> SET supplier_name = ( SELECT customer.name
> FROM customers
> WHERE customers.customer_id = supplier.supplier_id)
> WHERE EXISTS
> ( SELECT customer.name
> FROM customers
> WHERE customers.customer_id = supplier.supplier_id);
>
> Con lo cual puede que uno u otro sistema no sea sitácticamente igual.
>
>
>> - Sentencias de carga de datos en los mantenimientos (p.ej. cargar en un
>> array las l�neas de un pedido): no creo que sea necesario utilizar
>> sentencias SELECT tan complicadas que sean incompatibles entre distintas
>> BB.DD.
>>
>
> Bueno... depende... todo depende de lo que quieras buscar y como lo quieras
> traer. Yo utilizo select sencillas y otras donde hago una ristra de inner
> joins de varios niveles.
>
>> - Consultas para informes, extractos, etc.: aqu� s� creo que puede haber
>> diferencias entre distintos motores. Pero como ya comentamos este verano,
>> creo que este problema se puede resolver creando vistas en la BD y
>> entonces desde el programa nos limitaremos a poner "SELECT * FROM
>> VistaLoQueSea" salvando las incompatibilidades.
>>
>
> Las vistas pueden ser una solución válida...
>
>> Respecto a los lenguajes de manipulaci�n de la BD (crear la BD, usuarios,
>> tablas, etc.) s� es cierto que todos son distintos. Pero hoy dia te coges
>> cualquier programa de administraci�n de la BD y te genera un script
>> completo que puedes guardar en un campo memo de un dbf, y tener en ese dbf
>> varios registros, uno por cada BD que soporte tu programa.
>>
>
> Entonces tienes que aprender varios programas de administración de datos.
> Tambien has de aprender la sintáxis de cada uno para saber que campos y
> tipos crear. Aparte está de disparadores y esas cosillas...
>
>> Puede que haya otras caracter�sticas que diferencien las distintas BB.DD.
>> y que puedan influir puntualmente en el dise�o de un programa, pero
>> francamente creo que con un poco de imaginaci�n se pueden solucionar y no
>> ser un escollo para poder soportar, no digo todas, pero s� 2 � 3 BB.DD.
>> en un programa sin complicarse la existencia.
>>
>
> Con imaginación puedes solventar muchos escollos. Estoy seguro de ello.
> Pero imaginar cuesta tiempo... y además luego has de acordarte de lo
> imaginado para sueño por que si no... puede llegar a ser una pesadilla
> (José, permí­teme este juego de palabras sin ánimo de ofender ni nada por el
> estilo).
>
> Saludos,
> José Luis Capel
>
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Sun Oct 01, 2006 11:29 am

Paco,
> Creo que esperare, aunque ya empiezo a tener la necesidad.
Yo creo que podrí­as esperar para hacer una implementación definitiva,
pero para ir ganando horas de vuelo, creo que no hace falta esperar.
Aunque despues decidas usar otro motor y otro lenguaje, la experiencia y
práctica se adquiere solo con HCS (Horas Culo Silla)
Saludos,
Carlos.
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Sun Oct 01, 2006 11:37 am

José Luis,
Como siempre coincidimos plenamente. Hay un detalle...
> Como estamos en un foro de Xailer ....
No es un foro de xailer, o al menos no lo dice expresamente. En las news
de Olivares el foro es local.ozs.XBASE.sql no XAILER.
Carlos.
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Sun Oct 01, 2006 11:44 am

Jose,
> Seguramente yo no soy el más indicado para opinar en este punto, dada mi
> falta de experiencia, pero me voy a atrever a hacerlo...
Somos varios y si fuesemos los expertos no estarí­amos tan interesados en
la discusión.
> - Consultas para informes, extractos, etc.: aquí­ sí­ creo que puede haber
> diferencias entre distintos motores. Pero como ya comentamos este verano,
> creo que este problema se puede resolver creando vistas en la BD y entonces
> desde el programa nos limitaremos a poner "SELECT * FROM VistaLoQueSea"
> salvando las incompatibilidades.
Acá es donde no estoy seguro: Todos los motores soportan vistas?
> Puede que haya otras caracterí­sticas que diferencien las distintas BB.DD. y
> que puedan influir puntualmente en el diseño de un programa, pero
> francamente creo que con un poco de imaginación se pueden solucionar y no
> ser un escollo para poder soportar, no digo todas, pero sí­ 2 ó 3 BB.DD. en
> un programa sin complicarse la existencia.
Eso siempre y cuando mantengas tu uso de la BBDD en SELECTS, UPDATES e
INSERTs, pero que pasa si quiero usar triggers, campos
autoincrementales, stored procedures, etc.?
Tambien habrí­a que tener mucho cuidado con los tipos de datos
implementados por cada BBDD, ya que no todas las BBDD implementan los
mismo tipos, y mucho menos los BLOBs
Y no hablar de cosas pulidas como gestionar la replicación y cosas por
el estilo.
Es como intentar programar para Clipper, FoxBase y dBase al mismo
tiempo. Si, claro, son todas dbfs, y el append blank es igual y el
replace es igual.
Saludos,
Carlos
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Sun Oct 01, 2006 12:03 pm

Carlos,
>
> Como siempre coincidimos plenamente. Hay un detalle...
>
>> Como estamos en un foro de Xailer ....
>
> No es un foro de xailer, o al menos no lo dice expresamente. En las news
> de Olivares el foro es local.ozs.XBASE.sql no XAILER.
>
>
Ups... has sido un lapsus. El lector de noticias me pone Xailer como nombre
de grupo....
Saludos,
José Luis Capel

Return to “SQL”