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 » Sun Oct 01, 2006 12:16 pm

Efectivamente, despues de oiros a todos creo que me decido por:
Instalar MySql y empezar a hacer cositas a pedal (Crear tablas,
Consultillas, Etc)
Esperar a que Xailer me lo de hecho (JeJeJe), o casi hecho.
Muchas Gracias a todos.
Paco V
"Carlos Mora" <carlosmora@iespana.es> escribió en el mensaje
news:451f8a66@news.xailer.com...
> 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.
antonio.ortega
Posts: 124
Joined: Wed May 17, 2006 10:50 am

MySql

Postby antonio.ortega » Sun Oct 01, 2006 1:46 pm

Paco, lamentablemente Xailer ( por lo menos creo yo ) no te dará hechas las
consultas, ni te enseñara como administrar la base de datos, solo ( repito:
"en mi opinión" ) te facilitará la conexión y añadir y modificar filas (
registros ), y por cierto el primer paso es darnos cuenta que ya no
deberiamos pensar en funcion de registro por dbf , sino mas bien en
conjunto de datos.
Saludos.
Antonio F. Ortega
Armando Estrada Bucio
Posts: 19
Joined: Thu Dec 23, 2004 3:35 pm

MySql

Postby Armando Estrada Bucio » Sun Oct 01, 2006 3:16 pm

Paco:
Otra alternativa es la LIB FcsOdbs de Freddy Rodriguez
Con el uso de esta lib te olvidas de la sinaxis SQL basta con
aprender unas cuantas funciones y listo, sigues atacando las
tablas como si fueran DBFs.
Hay un excelente libro que te explica el funcionamiento
y el soporte tambien es inmejorable ah, y tambien hay
una pequeña aplicación ABM incluidos los fuentes.
Independientemente de lo que decidas, date una vuelta
por http://www.fcsodbc.com seguramente algo bueno
aprenderás.
Saludos, Armando
PD: no soy representante de FcsOdbc
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Sun Oct 01, 2006 4:45 pm

Manu,
Todo se reduce a una cuestión económica. Si el provecho que sacas supera el
coste invertido entonces todo es bueno y cualquier argumento técnico queda
casi en segundo plano.
Saludos,
José Luis Capel
"Manu" <manuexposito@terra.es> escribió en el mensaje
news:451f7f90@news.xailer.com...
> 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
>>
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Sun Oct 01, 2006 11:08 pm

Si te decantas por instalar MySQL te recomiendo que sea MySQL versión
5.0.24a es la que AB recomienda para producción.
Y de interface Eagle1+Xailer. En
http://es.groups.yahoo.com/group/eagle1/ puedes encontrar aun beta y
además un ejemplo de uso con Xailer. En unos dí­as pondré un
mantenimiento completo con Altas, Bajas, Modificaciones,
Búsquedas etc y la versión compilada para el xHarbour de la página de
Xailer... Te reto a que busques algo más fácil, rápido y seguro... y con
menos código. Eagle1 no usa ningún puente como ODBC o ADO ya que accede
directamente al cliente. Y los cuellos de botella está hechos en C con
lo que se consigue más velocidad de proceso, como bucles, transformación
de tipos de datos (incluidos los BLOB de imágenes y texto) tratamiento
de procedimientos almacenados etc y lo que es más importante no depende
de ninguna GUI por lo que podrás usarlo con Xailer, FiveWin, MiniGUI,
HwGUI etc o con el compilador que decidas Harbour, xHarbour, C3... y con
el compilador de C que quiera también Borland C. MinGW, Pelles C Pro ,
Visual C... Ademas podrás usarlo también en LINUX... Por ejemplo FcsOdbs
necesita de FiveWin, si no me equivoco, y de que tengas instalado el
ODBC de MySQL...
Perdonad que haya vendido la moto pero...
De cualquier modo en cuanto termine TDbf PRO pienso hacer una LIB nativa
para Xailer DataSet y DataSources :-)
Saludos
Paco V. escribió:
> Efectivamente, despues de oiros a todos creo que me decido por:
> Instalar MySql y empezar a hacer cositas a pedal (Crear tablas,
> Consultillas, Etc)
> Esperar a que Xailer me lo de hecho (JeJeJe), o casi hecho.
>
> Muchas Gracias a todos.
>
> Paco V
>
>
> "Carlos Mora" <carlosmora@iespana.es> escribió en el mensaje
> news:451f8a66@news.xailer.com...
>> 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.
>
>
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Sun Oct 01, 2006 11:19 pm

Estoy de acuerdo contigo... pero eso puede ser un poco superficial y a
la larga muy costoso.
Hoy en dí­a tienes que pensar primero en la estructura de la bases de
datos, Tablas, Relaciones, dominios, Disparadores, procedimientos
almacenados, indices, etc... eso te deberí­a llevar como mí­nimos el 75%
del tiempo y por último en lo que vas a usar de programación para
accederla...
Te puedo decir que en mi trabajo hemos tenido que perder más de un año
por culpa de lo que digo... y la aplicación funcionaba pero cuando se
empezó a meter caña a tope vimos que para el cálculo de la nómina de los
trabajadores de diputación habí­a que dejar los proceso toda la noche...
con algunos procedimientos almacenados se redujo a horas y con el cambio
a un gestor de bases de datos diferente y la reestructuración de las
tablas pasó a minutos...
José Luis Capel - escribió:
> Manu,
>
> Todo se reduce a una cuestión económica. Si el provecho que sacas supera el
> coste invertido entonces todo es bueno y cualquier argumento técnico queda
> casi en segundo plano.
>
> Saludos,
> José Luis Capel
>
>
> "Manu" <manuexposito@terra.es> escribió en el mensaje
> news:451f7f90@news.xailer.com...
>> 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
>>>
>
>
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Mon Oct 02, 2006 12:48 am

Ya he puesto el fichero en el grupo de Yahoo para Eagle1 el instalador
para Eagle1 v5.00 DEMO para Xailer y MySQL 5.0.x
Espero que lo prueben y me digan ;-)
Saludos
Manu escribió:
> Si te decantas por instalar MySQL te recomiendo que sea MySQL versión
> 5.0.24a es la que AB recomienda para producción.
> Y de interface Eagle1+Xailer. En
> http://es.groups.yahoo.com/group/eagle1/ puedes encontrar aun beta y
> además un ejemplo de uso con Xailer. En unos dí­as pondré un
> mantenimiento completo con Altas, Bajas, Modificaciones,
> Búsquedas etc y la versión compilada para el xHarbour de la página de
> Xailer... Te reto a que busques algo más fácil, rápido y seguro... y con
> menos código. Eagle1 no usa ningún puente como ODBC o ADO ya que accede
> directamente al cliente. Y los cuellos de botella está hechos en C con
> lo que se consigue más velocidad de proceso, como bucles, transformación
> de tipos de datos (incluidos los BLOB de imágenes y texto) tratamiento
> de procedimientos almacenados etc y lo que es más importante no depende
> de ninguna GUI por lo que podrás usarlo con Xailer, FiveWin, MiniGUI,
> HwGUI etc o con el compilador que decidas Harbour, xHarbour, C3... y con
> el compilador de C que quiera también Borland C. MinGW, Pelles C Pro ,
> Visual C... Ademas podrás usarlo también en LINUX... Por ejemplo FcsOdbs
> necesita de FiveWin, si no me equivoco, y de que tengas instalado el
> ODBC de MySQL...
> Perdonad que haya vendido la moto pero...
>
> De cualquier modo en cuanto termine TDbf PRO pienso hacer una LIB nativa
> para Xailer DataSet y DataSources :-)
>
> Saludos
>
> Paco V. escribió:
>> Efectivamente, despues de oiros a todos creo que me decido por:
>> Instalar MySql y empezar a hacer cositas a pedal (Crear tablas,
>> Consultillas, Etc)
>> Esperar a que Xailer me lo de hecho (JeJeJe), o casi hecho.
>>
>> Muchas Gracias a todos.
>>
>> Paco V
>>
>>
>> "Carlos Mora" <carlosmora@iespana.es> escribió en el mensaje
>> news:451f8a66@news.xailer.com...
>>> 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.
>>
>>
User avatar
jfgimenez
Site Admin
Posts: 5629
Joined: Mon Apr 06, 2015 8:48 pm
Contact:

MySql

Postby jfgimenez » Mon Oct 02, 2006 10:49 am

Carlos,
> Acá es donde no estoy seguro: Todos los motores soportan vistas?
Yo creo que sí. Incluso Access las soporta, y motores empotrados como SQLite
también.
> 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.?
Campos autoincrementales hay también en todos los motores, y los triggers,
stored procedures, etc., van dentro de la BD, y por lo tanto los escribes
específicamente para cada una de ellas, y el programa funcionará igual para
una o para otra.
> 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
Ya, pero al final por muchos tipos de datos que tenga la BD hay que
convertirlos a los tipos básicos de xbase (C, N, D, L y M). Lo que quiero
decir es que podrías usar unos tipos u otros en cada BD según su rendimiento
u otros factores, pero el programa sigue siendo el mismo.
> Y no hablar de cosas pulidas como gestionar la replicación y cosas por el
> estilo.
Vale, pero es precísamente este tipo de cosas las que te pueden hacer
decantarte por una BD u otra en función de las características y requisitos
de cada instalación.
> 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.
Ya, pero estamos hablando de mantener un mismo programa atacando distintas
BB.DD., y esto no es igual.
--
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 » Mon Oct 02, 2006 10:55 am

José Luis,
> 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.
Por supuesto, pudes hacer lo que quieras. Pero también puedes diseñar el
programa de forma que puedas atacar a más de una BD sin complicarte
demasiado, vamos creo yo.
> 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...
Tampoco creo que sea muy complicado. Complicado es hablar varios idiomas,
pero conocer varios lenguajes de programación es mucho más fácil que hablar
un idioma, y si se trata de conocer las diferencias entre distintos
dialectos de un mismo lenguaje (SQL), pues es más fácil todavía.
> 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).
No te preocupes ;-)
--
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 » Mon Oct 02, 2006 10:59 am

Manu,
> - 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.
Vale, perfecto, ¿y no se puede conseguir también lo contrario? Es decir, que
el programa sea lo más independiente posible de los datos.
--
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
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Mon Oct 02, 2006 5:12 pm

Por supuesto Jose...
Para eso están en Delphi y Xailer los DataSets y los DataSources
El datasource se entiende con la base de datos y es especí­fico de cada
gestor de bases de datos y los DataSet que recogen la informacion
filtrada por los DataSources y se la "entregan" al programa
(datacontrols) de una manera única... pero para que esto sea posible
suelen ser muy "generales" con lo que dejan escapar "sutilezas" que solo
son permitidas si haces uso directo del cliente...
De cualquier modo en un 75% nos podremos conformar con lo que
proporciona Xailer.
El otro tema importante es los tipos de datos, quieras que no es un
quebradero de cabeza, sobre todo para hacer el DataSource ya que la
transformación debe ser doble, de ida y vuelta y los WHERE pueden ser
mortales cuando no hay definidas KEYs... Aveces no se puede obligar al
programador que las tenga definidas, qué hacemos entoces?
Bueno ahí­ queda eso!!! ;-)
Jose F. Gimenez escribió:
> Manu,
>
>> - 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.
>
> Vale, perfecto, ¿y no se puede conseguir también lo contrario? Es decir, que
> el programa sea lo más independiente posible de los datos.
>
User avatar
ignacio
Site Admin
Posts: 8693
Joined: Mon Apr 06, 2015 8:00 pm
Location: Madrid, Spain
Contact:

MySql

Postby ignacio » Mon Oct 02, 2006 6:26 pm

Manu,
> (datacontrols) de una manera única... pero para que esto sea posible
> suelen ser muy "generales" con lo que dejan escapar "sutilezas" que solo
> son permitidas si haces uso directo del cliente...
Dame un ejemplo. Gracias
> De cualquier modo en un 75% nos podremos conformar con lo que proporciona
> Xailer.
Dame ejemplos del otro 25%. Gracias
> El otro tema importante es los tipos de datos, quieras que no es un
> quebradero de cabeza, sobre todo para hacer el DataSource ya que la
> transformación debe ser doble, de ida y vuelta y los WHERE pueden ser
> mortales cuando no hay definidas KEYs... Aveces no se puede obligar al
> programador que las tenga definidas, qué hacemos entoces?
No, no lo es, depende de como lo tengas implementado. En ODBCDataSource te
aseguro que no hay ninguna transformación en la recogida de datos de un
select. De hecho te proporcione el código en su día y puedes verlo. En
cuanto a ADO estoy convencido que tampoco lo hace pues no es realmente
necesario. Fw utilizaba un proceso de conversión que lo relentizaba mucho,
pero eso es otra historia.
En cuanto a salvado de datos, no se como lo haces tu con MySQL, pero todos
los motores que yo conozco utiilzan como sistema único de entrada de datos
los comandos INSERT y UPDATE que son ASCII puro y duro (excepto importación
de datos con SELECT INTO), y por lo tanto no hay más narices que el propio
servidor SQL, que NO Xailer, haga la conversiones necesarias
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Manu" <manuexposito@terra.es> escribió en el mensaje
news:45212b91$1@news.xailer.com...
> Por supuesto Jose...
> Para eso están en Delphi y Xailer los DataSets y los DataSources
> El datasource se entiende con la base de datos y es específico de cada
> gestor de bases de datos y los DataSet que recogen la informacion filtrada
> por los DataSources y se la "entregan" al programa (datacontrols) de una
> manera única... pero para que esto sea posible suelen ser muy "generales"
> con lo que dejan escapar "sutilezas" que solo son permitidas si haces uso
> directo del cliente...
> De cualquier modo en un 75% nos podremos conformar con lo que proporciona
> Xailer.
>
> El otro tema importante es los tipos de datos, quieras que no es un
> quebradero de cabeza, sobre todo para hacer el DataSource ya que la
> transformación debe ser doble, de ida y vuelta y los WHERE pueden ser
> mortales cuando no hay definidas KEYs... Aveces no se puede obligar al
> programador que las tenga definidas, qué hacemos entoces?
>
> Bueno ahí queda eso!!! ;-)
>
> Jose F. Gimenez escribió:
>> Manu,
>>
>>> - 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.
>>
>> Vale, perfecto, ¿y no se puede conseguir también lo contrario? Es decir,
>> que el programa sea lo más independiente posible de los datos.
>>
Ignacio Ortiz de Zúñiga
[Equipo de Xailer / Xailer team]
http://www.xailer.com
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Mon Oct 02, 2006 8:07 pm

Ignacio,
>> (datacontrols) de una manera única... pero para que esto sea posible
>> suelen ser muy "generales" con lo que dejan escapar "sutilezas" que solo
>> son permitidas si haces uso directo del cliente...
>
> Dame un ejemplo. Gracias
No manejo en detalle el tema de los datasets, pero algo que se me ocurre
que podrí­a variar es hacer ese tipo de consultas que se soportan en una
BBDD y en otras no, como el tema de la columnas de acumulados por el
cual estube preguntando hace poco.
Otra serí­a (ojo, solo especulo) como obtener el LastInsertID() en el
caso de los IDs autoincrementales.
>> El otro tema importante es los tipos de datos, quieras que no es un
>> quebradero de cabeza, sobre todo para hacer el DataSource ya que la
>> transformación debe ser doble, de ida y vuelta y los WHERE pueden ser
>> mortales cuando no hay definidas KEYs... Aveces no se puede obligar al
>> programador que las tenga definidas, qué hacemos entoces?
>
> No, no lo es, depende de como lo tengas implementado. En ODBCDataSource te
> aseguro que no hay ninguna transformación en la recogida de datos de un
> select. De hecho te proporcione el código en su dí­a y puedes verlo. En
> cuanto a ADO estoy convencido que tampoco lo hace pues no es realmente
> necesario. Fw utilizaba un proceso de conversión que lo relentizaba mucho,
> pero eso es otra historia.
>
> En cuanto a salvado de datos, no se como lo haces tu con MySQL, pero todos
> los motores que yo conozco utiilzan como sistema único de entrada de datos
> los comandos INSERT y UPDATE que son ASCII puro y duro (excepto importación
> de datos con SELECT INTO), y por lo tanto no hay más narices que el propio
> servidor SQL, que NO Xailer, haga la conversiones necesarias
Una pregunta: Como sabes cual es el ID de un INSERT con clave
autoincremental en SQL Server?
Creo que no hay discusión sobre INSERTs o UPDATES genéricos. El punto al
que se refiere Manu es a los items como los anteriores donde la
implementación de ciertas caracterí­sticas deseables y necesarias
requieren de algunos apaños diferentes segun la BBDD que uses.
Saludos,
Carlos.
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Mon Oct 02, 2006 10:09 pm

Manu,
Mi respuesta anterior es para justificar a los que quieren tener el mismo
programa sustentando diferentes bases de datos. Obviamente una buena
implementación de bases de datos puede ser muy parecida entre diferentes
bases de datos. Se pueden obtener resultados parejos aunque para ello
tengas que hacer cosas ligeramente diferentes. Estos cambios entre
diferentes bases de datos cuesta tiempo... y dinero. Y la administración de
cada base de datos tambien es costosa en tiempo.... y dinero. Entonces...
los coste de implementación de cada nueva base de datos que quieras
soportar bien podrí­a resumirse en la siguiente ecuación (permitidme este
ejercicio que no deja de ser algo más bien lúdico que empí­rico):
nCoste := nCosteInicial * ( nNumeroBases - nNumeroBases * nFactorNoHecho)
nCoste es el coste resultante.
nCosteInicial es el coste de implementación de la primera base
nNumeroBases son (en número) las nuevas bases a implementar
nFactorNoHecho es (de cero a uno) el porcentaje que se presupunone hay que
desarrollar nuevo.
Creo que esta ecuación es aplicable a cada uno de los elementos que
interviene en la creación de software:
- Analisis Base datos
- Análisis Software
- Programación software
- Programación base datos
- Administración base datos
- Soporte
Luego... Habrí­a que sumar los ingresos derivados de las ventas y soporte del
software y ver la desviación de inversión respecto a resultados.
Saludos,
José Luis Capel
> Estoy de acuerdo contigo... pero eso puede ser un poco superficial y a
> la larga muy costoso.
> Hoy en dí­a tienes que pensar primero en la estructura de la bases de
> datos, Tablas, Relaciones, dominios, Disparadores, procedimientos
> almacenados, indices, etc... eso te deberí­a llevar como mí­nimos el 75%
> del tiempo y por último en lo que vas a usar de programación para
> accederla...
> Te puedo decir que en mi trabajo hemos tenido que perder más de un año
> por culpa de lo que digo... y la aplicación funcionaba pero cuando se
> empezó a meter caña a tope vimos que para el cálculo de la nómina de los
> trabajadores de diputación habí­a que dejar los proceso toda la noche...
> con algunos procedimientos almacenados se redujo a horas y con el cambio
> a un gestor de bases de datos diferente y la reestructuración de las
> tablas pasó a minutos...
>
>
> José Luis Capel - escribió:
>> Manu,
>>
>> Todo se reduce a una cuestión económica. Si el provecho que sacas supera
>> el
>> coste invertido entonces todo es bueno y cualquier argumento técnico
>> queda casi en segundo plano.
>>
>> Saludos,
>> José Luis Capel
>>
>>
>> "Manu" <manuexposito@terra.es> escribió en el mensaje
>> news:451f7f90@news.xailer.com...
>>> 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
>>>>
>>
>>
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Mon Oct 02, 2006 10:15 pm

Carlos,
> No manejo en detalle el tema de los datasets, pero algo que se me ocurre
> que podrí­a variar es hacer ese tipo de consultas que se soportan en una
> BBDD y en otras no, como el tema de la columnas de acumulados por el
> cual estube preguntando hace poco.
Esto no es inherente a los datasources/datasets. En ADO (que usa la misma
idea) tu haces el SELECT que necesites. El resultado lo manejas con ADO (o
con los datasets de Xailer) y, como mucho, añades, borras o modificas sobre
ese conjunto de resultados.
> Otra serí­a (ojo, solo especulo) como obtener el LastInsertID() en el
> caso de los IDs autoincrementales.
>
Creo que podrí­as hacer o bien un SELECT LAST o un SELECT MAX.
> Una pregunta: Como sabes cual es el ID de un INSERT con clave
> autoincremental en SQL Server?
Después de hacer el INSERT ya tienes disponible el valor del autoincremental
(por lo menos en ADO).
Saludos,
José Luis Capel
Manu
Posts: 108
Joined: Sun Sep 24, 2006 2:28 pm

MySql

Postby Manu » Mon Oct 02, 2006 11:56 pm

La verdad es que no querí­a entrar en polémicas que no conducen a ninguna
parte pero tampoco me gustan los "malentendidos"...
Si lees todos los mensajes yo dije que habí­a que trabajar y dedicar
mucho tiempo a hacer una buena estructura de bases de datos para que
estas fueran automantenibles y que lo de menos es el programa que las
accede... que podrí­a estar hecho en Delphi, VB o en Xailer, es más, aquí­
recalqué "que es el que yo uso"... Expliqué las tres capas que en
principio deberí­amos de considerar: reglas de integridad y coherencia,
dominios í­ndices, estructuras etc, las reglas de negocio y el programa
para acceder a la base de datos... Y me reafirmo cualquier base de datos
que diseñemos para un programa concreto estará mal implementa desde el
principio aunque funcione inicialmente tarde o temprano habrí­a que hacer
remiendos más o menos costosos en tiempo, trabajo y por supuesto en
dinero...
A todo eso me dijo Jose esto:
//-----------
Vale, perfecto, ¿y no se puede conseguir también lo contrario? Es decir,
que
el programa sea lo más independiente posible de los datos.
//-----------
De ahí­ que yo dijera que para eso estaban los dataset y datasources de
por ejemplo, Xailer... para las reglas "más o menos básicas" esto está
perfecto... pero cuando te quieres meter en profundidad y además en
velocidad tienes que usar accesos directo al cliente quieras o no... de
ahí­ que pusiera un ejemplo real de mi trabajo... y quieras o no esto
hace que cada vez que cambies la base de datos tengas que hacer
modificaciones en tu programa... recuerda que en Delphi utilizan las
alias que son administradas desde el gestor que accede al BDE o Borland
DataBase engine (antiguamente IDEAPI) esto en principio supondrí­a que
con el sólo cambiar el Alias para que apunte a otro gestor de BBDD ya
pirula perfectamente... tengo unos añitos de experiencia en este sentido
y para nada es tan fácil como eso simplemente... hemos pasado por
Access, INGRES, Interbase y ahora por Oracle.
Tanto el ejemplo que me pides como del 25% que yo he calculado "por
encima", posiblemente será más, lo tendrás diariamente cuando nuestros
compañeros y sin embargo amigos tengan aplicaciones funcionando y
decidan un dí­a cambiar de SQLServer a Oracle por ejemplo, o hacer algo
como lo que indica José Luis...
Por otro lado, cuando he mencionado los cuellos de botella como por
ejemplo la conversión de tipos de datos, te aseguro que para mí­ ha sido
lo más dificil de resolver para que esto no fuera un retardo. Es cierto
que en una reunión del GO2000 me mostraste como lo hací­as tú y yo te
mostré como lo hací­a yo pero no me proporcionaste el código lo vi como
tú el mí­o... hubo un momento en que pedí­ información más detallada de
los dataset y datasources y muy gentilmente me mandaste los referidos a
DBF para usarlo como modelo... ahora dentro de poco lo volveré a pedir
para hacer esos componentes para MySQL y más adelante seguramente para
más gestores si realmente merece la pena.
De lo que recuerdo de aquel dí­a sí­ tenias que hacer conversiones, lo
primero es que las bases de datos tienen más tipos de datos que C, y
este, a su vez, más que xBase y por supuesto lo que devuelve ODBC lo
tienes que pasar al tipo de xBase o sea a una variable... o sea a un ITEM...
A diferencia de como yo he implementado Condor1 y Eagle1 que no llevan
bucle de conversión...
José Alfonso que vino a mi casa pudo observar la diferencia de tiempo
del mismo programa usando Condor1 y usando otras clases... él habló en
la entrevista que le hicieron en Radio CresWin de unas 70 veces más rápido.
Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
para hacer un EDIT o un borrado ya que me imagino que para fabricar el
WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
por hacer una comparativa la clase TODBCTable que serí­a la equivalente a
Xailer no tiene esa restricciones.
Otro ejemplo para decirte que hay veces que las generalidades no
funcionan. Una tabla de access con un tipo de datos Datetime y que
además este campo sea el campo de clave única para que se puedan hacer
los edit y deletes con Xailer, por lógica te fallará... pruébalo y luego
te digo porqué... si te falla, claro.
o cuando uses los tipos TEXT de algunas BBDD o BLOB o unicode... intenta
hacer insert o updates estandar con eso y verás que no es tan fácil...
con algo muy generalista.
En todo momento quiero que nos tomemos esto como una crí­tica
constructiva y no para crear polémicas... pienso que es una manera de
que todos aprendamos un poco más cada dí­a y crezcamos como programadores.
Ignacio Ortiz de Zúñiga escribió:
> Manu,
>
>> (datacontrols) de una manera única... pero para que esto sea posible
>> suelen ser muy "generales" con lo que dejan escapar "sutilezas" que solo
>> son permitidas si haces uso directo del cliente...
>
> Dame un ejemplo. Gracias
>
>> De cualquier modo en un 75% nos podremos conformar con lo que proporciona
>> Xailer.
>
> Dame ejemplos del otro 25%. Gracias
>
>> El otro tema importante es los tipos de datos, quieras que no es un
>> quebradero de cabeza, sobre todo para hacer el DataSource ya que la
>> transformación debe ser doble, de ida y vuelta y los WHERE pueden ser
>> mortales cuando no hay definidas KEYs... Aveces no se puede obligar al
>> programador que las tenga definidas, qué hacemos entoces?
>
> No, no lo es, depende de como lo tengas implementado. En ODBCDataSource te
> aseguro que no hay ninguna transformación en la recogida de datos de un
> select. De hecho te proporcione el código en su dí­a y puedes verlo. En
> cuanto a ADO estoy convencido que tampoco lo hace pues no es realmente
> necesario. Fw utilizaba un proceso de conversión que lo relentizaba mucho,
> pero eso es otra historia.
>
> En cuanto a salvado de datos, no se como lo haces tu con MySQL, pero todos
> los motores que yo conozco utiilzan como sistema único de entrada de datos
> los comandos INSERT y UPDATE que son ASCII puro y duro (excepto importación
> de datos con SELECT INTO), y por lo tanto no hay más narices que el propio
> servidor SQL, que NO Xailer, haga la conversiones necesarias
>
> Un saludo,
Guest

MySql

Postby Guest » Tue Oct 03, 2006 8:24 am

Manu,
Perdoname, pero has entrado tu en polemica diciendo claramenete que Xailer
no es capaz de hacer el 25% de operaciones que se pueden hacer con un motor
SQL, Releete a ti mismo por favor.
Y me reafirmo cualquier base de datos
> que diseñemos para un programa concreto estará mal implementa desde el
> principio aunque funcione inicialmente tarde o temprano habría que hacer
> remiendos más o menos costosos en tiempo, trabajo y por supuesto en
> dinero...
Las BD se diseñan con los adminitradores que incluyen las mismas y no existe
ninguna necesidad de pensar que con que libreria se le va atacar. Vale para
cualquiera. Eso es absurdo.
>
> De ahí que yo dijera que para eso estaban los dataset y datasources de por
> ejemplo, Xailer... para las reglas "más o menos básicas" esto está
> perfecto... pero cuando te quieres meter en profundidad y además en
> velocidad tienes que usar accesos directo al cliente quieras o no... de
Y el ejemplo.
> ahí que pusiera un ejemplo real de mi trabajo... y quieras o no esto hace
> que cada vez que cambies la base de datos tengas que hacer modificaciones
> en tu programa
Si te refieres a la ubicación de la BD tan sólo hay que cambiar el dato
cConnect del Datasource.
> alias que son administradas desde el gestor que accede al BDE o Borland
> DataBase engine (antiguamente IDEAPI)
Hace mucho que Borland abandono el BDE me temo.
> con el sólo cambiar el Alias para que apunte a otro gestor de BBDD ya
> pirula perfectamente... tengo unos añitos de experiencia en este sentido y
> para nada es tan fácil como eso simplemente... hemos pasado por Access,
> INGRES, Interbase y ahora por Oracle.
Y que tiene que ver eso con que Xailer no pueda acometer el 25% o más de
operaciones con un motor SQL
>
> Tanto el ejemplo que me pides como del 25% que yo he calculado "por
> encima", posiblemente será más, lo tendrás diariamente cuando nuestros
> compañeros y sin embargo amigos tengan aplicaciones funcionando y decidan
> un día cambiar de SQLServer a Oracle por ejemplo, o hacer algo como lo que
> indica José Luis...
Estas mezclando churras con merinas. Una cosa es que no sea sencillo pasar
de un gestor BD a otro y otra cosa muy distinta es que Xailer no sea capaz
de exprimir a ambos al 100%
>
> Por otro lado, cuando he mencionado los cuellos de botella como por
> ejemplo la conversión de tipos de datos, te aseguro que para mí ha sido lo
> más dificil de resolver para que esto no fuera un retardo. Es cierto que
> en una reunión del GO2000 me mostraste como lo hacías tú y yo te mostré
> como lo hacía yo
Jamas me enseñaste tu codigo, y tampoco hice yo nada por verlo.
> tú el mío... hubo un momento en que pedí información más detallada de los
> dataset y datasources y muy gentilmente me mandaste los referidos a DBF
> para usarlo como modelo...
Se te mando el ODBC completo.
> De lo que recuerdo de aquel día sí tenias que hacer conversiones, lo
> primero es que las bases de datos tienen más tipos de datos que C, y este,
> a su vez, más que xBase y por supuesto lo que devuelve ODBC lo tienes que
> pasar al tipo de xBase o sea a una variable... o sea a un ITEM...
> A diferencia de como yo he implementado Condor1 y Eagle1 que no llevan
> bucle de conversión...
xHarbour, que no Xailer, sólo entiende de HB_ITEMS. Es imposible no
utilizarlos, al final, tarde o temprano utilizas el HB_ITEM quieras o no. Y
en cuanto a la conversión te diré que en absoluto. Hay que distinguir entre
conversión y casting, y te aseguro que no es lo mismo.
> José Alfonso que vino a mi casa pudo observar la diferencia de tiempo del
> mismo programa usando Condor1 y usando otras clases... él habló en la
> entrevista que le hicieron en Radio CresWin de unas 70 veces más rápido.
Quien ha hablado de velocidad. No he sido yo. No se si serás más rápido que
Xailer, seguramente si, pero te aseguro que la velocidad con que muestre
Xailer actualmente los datos no es nada despreciable. Más que suficiente.
>
> Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
> para hacer un EDIT o un borrado ya que me imagino que para fabricar el
> WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
> crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
Eso no es cierto. Sólo en el caso de ODBC es necesario que exista una clave
primaria. Y se ha hecho para asegurar la integridad de los datos, es decir,
por seguridad. No me habría costado nada haber hecho un UPDATE a lo bestia,
pero no me parece seguro.
> por hacer una comparativa la clase TODBCTable que sería la equivalente a
> Xailer no tiene esa restricciones.
Entonces tendrá problemas de seguridad porque no podrás asegurar que un
UPDATE sólo afecta a una fila.
> Otro ejemplo para decirte que hay veces que las generalidades no
> funcionan. Una tabla de access con un tipo de datos Datetime y que además
> este campo sea el campo de clave única para que se puedan hacer los edit y
> deletes con Xailer, por lógica te fallará... pruébalo y luego te digo
> porqué... si te falla, claro.
Pruebalo tu primero, y me haces el ejemplo. Te recuerdo que Xailer en ODBC
es capaz de manejar los campos dateteime como cadenas y por tanto no se
pierde información de la hora.
> o cuando uses los tipos TEXT de algunas BBDD o BLOB o unicode... intenta
> hacer insert o updates estandar con eso y verás que no es tan fácil... con
> algo muy generalista.
Precisamente toda esa complejidad es la que te esconden motores como ODBC o
ADO.
> En todo momento quiero que nos tomemos esto como una crítica constructiva
> y no para crear polémicas... pienso que es una manera de que todos
> aprendamos un poco más cada día y crezcamos como programadores.
Por supuesto que no.
Un saludo,
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Tue Oct 03, 2006 8:51 am

Manu,
Siento curiosidad de saber como haces esto:
>
> Por ejemplo los dataset de Xailer necesitan forzosamente un clave única
> para hacer un EDIT o un borrado ya que me imagino que para fabricar el
> WHERE de la sentencia lo necesitas... eso es obligar por imperativo o a
> crear la clave única o ha hacerlo tu mismo con una clase de tipo Query,
> por hacer una comparativa la clase TODBCTable que serí­a la equivalente a
> Xailer no tiene esa restricciones.
Imagí­nate que necesitas traerte estos datos:
SELECT Apellido FROM MiTabla WHERE Apellido = 'Capel'
Esa tabla te devuelve 2 registros (yo y mi hijo).
Modifico uno de los registros y actualizo la base de datos.
¿Que ocurre? ¿Como haces esto?
Antes que me digas nada... esto es una muy mala práctica de programación
Sql. Solo te lo pongo como ejemplo que tiene difí­cil solución (o no
tiene).
Saludos,
José Luis Capel
PD: en ADO es posible que te modifique tooodos los registros cuyo apellido
sea 'Capel' (no lo he probado).
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Tue Oct 03, 2006 9:14 am

José Luis,
> Creo que podrí­as hacer o bien un SELECT LAST o un SELECT MAX.
No. Lo insertado no es necesariamente el último, considerando inserts
concurrentes podrí­a ocacionar que te retorne la fila que insertó el otro
proceso.
>> Una pregunta: Como sabes cual es el ID de un INSERT con clave
>> autoincremental en SQL Server?
>
> Después de hacer el INSERT ya tienes disponible el valor del autoincremental
> (por lo menos en ADO).
A que te refieres con 'tener disponible'? Seguramente al hacer un select
* mrecibo todo, pero nada me asegura que el último es el que yo inserté.
Por eso existe en MySQL el LastInsertId().
Saludos.
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Tue Oct 03, 2006 9:24 am

José Luis,
> Esto no es inherente a los datasources/datasets. En ADO (que usa la misma
> idea) tu haces el SELECT que necesites. El resultado lo manejas con ADO (o
> con los datasets de Xailer) y, como mucho, añades, borras o modificas sobre
> ese conjunto de resultados.
Primero, creo que la discusión se ha desviado. Lo que entiendo que es la
opinión de Manu y que comparto, es que no se puede usar SQL genérico,
que es diferente según el motor que uses. No puedes usar el mismo SELECT
independientemente del motor segun lo visto en mi mensaje. Creo que esa
idea de que alguien ha atacado a Xailer (¡Sacrí­lego, a la puta hoguera!)
y que es lo que me parece arranca con los flames, no tiene sentido.
Xailer solo accede y no es responsable de la respuesta de las BBDD,
actúa solo de cliente inteligente y no tiene sentido discutirlo.
Saludos
User avatar
ignacio
Site Admin
Posts: 8693
Joined: Mon Apr 06, 2015 8:00 pm
Location: Madrid, Spain
Contact:

MySql

Postby ignacio » Tue Oct 03, 2006 9:32 am

Carlos,
> A que te refieres con 'tener disponible'? Seguramente al hacer un select *
> mrecibo todo, pero nada me asegura que el último es el que yo inserté. Por
> eso existe en MySQL el LastInsertId().
SQLServer en mi opinión lo hace de una forma mucho más elegante ya que es
completamente automático, y no hay necesidad de recuperar nada a través de
una función. Este misma problema lo tiene FireBird con los 'Generators'.
Lo que comenta José Luis, es que en el momento que haces un
oRecordSet:AddNew(). En ese mismo momento ya puedes interrogar por el valor
del campo incremental y te da su valor. No hay nada más que hacer.
En el caso de FireBird y supongo que también MySQL tienes que llamar a la
función que te da el número del contador y a continuación lo incrementea en
1, y luego dicho número eres tu el responsable de guardarlo en el campo en
cuestion. Por lo tanto es un sistema bastante manual, y además no te
garantiza que tu número sea el último, sino simplemente, te garantiza que tu
número es único, pues el siguiente que llame a la función le van a devolver
el siguiente número, y es probable que el otro usuario realice el alta antes
que tu.
Toda esta complejidad desaparece en cualquier caso para cualquier BD cuando
se utilizan con ADO.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Carlos Mora" <carlos.mora@atisa.es> escribió en el mensaje
news:45220df4@news.xailer.com...
> José Luis,
>> Creo que podrías hacer o bien un SELECT LAST o un SELECT MAX.
>
> No. Lo insertado no es necesariamente el último, considerando inserts
> concurrentes podría ocacionar que te retorne la fila que insertó el otro
> proceso.
>
>>> Una pregunta: Como sabes cual es el ID de un INSERT con clave
>>> autoincremental en SQL Server?
>>
>> Después de hacer el INSERT ya tienes disponible el valor del
>> autoincremental
>> (por lo menos en ADO).
>
> A que te refieres con 'tener disponible'? Seguramente al hacer un select *
> mrecibo todo, pero nada me asegura que el último es el que yo inserté. Por
> eso existe en MySQL el LastInsertId().
>
> Saludos.
Ignacio Ortiz de Zúñiga
[Equipo de Xailer / Xailer team]
http://www.xailer.com
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Tue Oct 03, 2006 9:35 am

Carlos,
>> Creo que podrías hacer o bien un SELECT LAST o un SELECT MAX.
>
> No. Lo insertado no es necesariamente el último, considerando inserts
> concurrentes podría ocacionar que te retorne la fila que insertó el otro
> proceso.
Pues no se me ocurre ahora mismo otra forma de consultarlo.. Normalmente
los autoincrementales son valores numéricos positivos o negativos (esto ya
se sabe antes de hacer el select). Entonces el último disponible es el
LAST/MAX que hagas en la consulta. Si en ese momento hay 7 terminales
haciendo inserts... ¿que tiene que hacer el motor de base de datos: esperar
a que terminen todos los inserts para darte a ti la información correcta? ¿Y
si hay 4 más en cola? La idea del autoincremental es que tu no te tengas
que preocupar de cual es el último, de eso ya se encarga el motor de base de
datos. Por lo tanto, el valor devuelto en el SELECT LAST/MAX es válido para
el momento justo de la consulta.
>
>>> Una pregunta: Como sabes cual es el ID de un INSERT con clave
>>> autoincremental en SQL Server?
>>
>> Después de hacer el INSERT ya tienes disponible el valor del
>> autoincremental
>> (por lo menos en ADO).
>
> A que te refieres con 'tener disponible'? Seguramente al hacer un select *
> mrecibo todo, pero nada me asegura que el último es el que yo inserté. Por
> eso existe en MySQL el LastInsertId().
>
Con Ado, si tienes establecida la propiedad del recordset "Update Resync" a
adResyncAutoIncrement, cada actualización de registro (si es un insert) te
devuelve el valor del autoincremental.
Saludos,
José Luis Capel
jose.luis
Posts: 1633
Joined: Fri Oct 14, 2005 10:56 pm

MySql

Postby jose.luis » Tue Oct 03, 2006 9:39 am

Carlos,
> Primero, creo que la discusión se ha desviado. Lo que entiendo que es la
> opinión de Manu y que comparto, es que no se puede usar SQL genérico, que
> es diferente según el motor que uses. No puedes usar el mismo SELECT
> independientemente del motor segun lo visto en mi mensaje. Creo que esa
> idea de que alguien ha atacado a Xailer (¡Sacrílego, a la puta hoguera!) y
> que es lo que me parece arranca con los flames, no tiene sentido. Xailer
> solo accede y no es responsable de la respuesta de las BBDD, actúa solo de
> cliente inteligente y no tiene sentido discutirlo.
Justamente es lo que quiero decir... ADO y los Datasources de Xailer no
intervienen en la selección de datos. Solo en los datos resultantes.
Saludos,
José Luis Capel
User avatar
ignacio
Site Admin
Posts: 8693
Joined: Mon Apr 06, 2015 8:00 pm
Location: Madrid, Spain
Contact:

MySql

Postby ignacio » Tue Oct 03, 2006 9:50 am

Carlos,
> Primero, creo que la discusión se ha desviado. Lo que entiendo que es la
> opinión de Manu y que comparto, es que no se puede usar SQL genérico, que
> es diferente según el motor que uses.
La comparto igualmente, pero no puedo compartir que para sacar partido de un
motor SQL al 100% haya que usar un cliente nativo.
>Creo que esa idea de que alguien ha atacado a Xailer (¡Sacrílego, a la
>puta hoguera!)
De Manu: [De cualquier modo en un 75% nos podremos conformar con lo que
proporciona Xailer.]
Está escrito unos mensajes más arriba. Yo no me invento nada. Si alquien
ataca a nuestro producto exigo demostraciones o disculpas. Lo que prefiera.
> y no tiene sentido discutirlo.
Tienes toda la razón. Yo por mi parte abandono este hilo definitivamente.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Carlos Mora" <carlos.mora@atisa.es> escribió en el mensaje
news:45221035@news.xailer.com...
> José Luis,
>> Esto no es inherente a los datasources/datasets. En ADO (que usa la
>> misma
>> idea) tu haces el SELECT que necesites. El resultado lo manejas con ADO
>> (o
>> con los datasets de Xailer) y, como mucho, añades, borras o modificas
>> sobre
>> ese conjunto de resultados.
> Primero, creo que la discusión se ha desviado. Lo que entiendo que es la
> opinión de Manu y que comparto, es que no se puede usar SQL genérico, que
> es diferente según el motor que uses. No puedes usar el mismo SELECT
> independientemente del motor segun lo visto en mi mensaje. Creo que esa
> idea de que alguien ha atacado a Xailer (¡Sacrílego, a la puta hoguera!) y
> que es lo que me parece arranca con los flames, no tiene sentido. Xailer
> solo accede y no es responsable de la respuesta de las BBDD, actúa solo de
> cliente inteligente y no tiene sentido discutirlo.
>
> Saludos
Ignacio Ortiz de Zúñiga
[Equipo de Xailer / Xailer team]
http://www.xailer.com
Carlos Mora
Posts: 88
Joined: Fri Jul 28, 2006 9:36 am

MySql

Postby Carlos Mora » Tue Oct 03, 2006 12:54 pm

Ignacio,
>> A que te refieres con 'tener disponible'? Seguramente al hacer un select *
>> mrecibo todo, pero nada me asegura que el último es el que yo inserté. Por
>> eso existe en MySQL el LastInsertId().
>
> SQLServer en mi opinión lo hace de una forma mucho más elegante ya que es
> completamente automático, y no hay necesidad de recuperar nada a través de
> una función. Este misma problema lo tiene FireBird con los 'Generators'.
> Lo que comenta José Luis, es que en el momento que haces un
> oRecordSet:AddNew(). En ese mismo momento ya puedes interrogar por el valor
> del campo incremental y te da su valor. No hay nada más que hacer.
Si tienes el valor disponible es que ya existe, sino no podrí­as fiarte.
Hará un 'append blank' para obtener el valor o algo así­, y luego
modificará el registro, pero no existe forma de anticipar ese valor en
el cliente sin haberlo insertado antes.
> En el caso de FireBird y supongo que también MySQL tienes que llamar a la
> función que te da el número del contador y a continuación lo incrementea en
> 1, y luego dicho número eres tu el responsable de guardarlo en el campo en
> cuestion. Por lo tanto es un sistema bastante manual, y además no te
> garantiza que tu número sea el último, sino simplemente, te garantiza que tu
> número es único, pues el siguiente que llame a la función le van a devolver
> el siguiente número, y es probable que el otro usuario realice el alta antes
> que tu.
FireBird es totalmente diferente de MySQL, MySQL gestiona internamente
los autoincrementales.
No es necesario tener un ID que sea último, necesito que sea único, y se
genera al insertar el registro. Puede ser que el cliente ADO gestione la
recuperación del ID, es probable. Lo unico que te puedo garantizar es
que para que un ID sea realmente un ID tiene que existir, por lo que si
AddNew() ya recupera un ID, es porque ha hecho un insert blank o
similar. Eso es fácil de demostrar: Usanod dos clientes, en una hago un
AddNew, luego lo hago en el otro cliente, y en el crimero hago un
cancel. Que sucede con el ID no usado?
> Toda esta complejidad desaparece en cualquier caso para cualquier BD cuando
> se utilizan con ADO.
Es probable, ya aprenderé un poco más al respecto.
Un saludo,
Carlos

Return to “SQL”