A, pero ya estamos hablando de otra cosa. En esa situación también puede pasar que las tablas NO estén en el mismo servidor...
Igual si nos metemos en terreno distribuido, nos vamos a ir de mambo... 8-) Hoy día mi recomendación (de nuevo, sugerencia, no dogma) es: si vas a hacer una aplicación distribuida, tratá de evitar todo lo que puedas el mundo com. Indigo, te queremos!!! Saludos, /ms On 6/6/07, Ricardo Aidelman <[EMAIL PROTECTED]> wrote:
Perdón, Martín, pero si pones una .dll en el COM+ del server, el trabajo lo hace el server. Pensalo..... tal vez hasta se podría escribir un articulo...... Yo le pondría "El servidor del pobre" :-) Un abrazo ricardo aidelman (socio 1545) praxis computación buenos aires argentina ------------------------------ *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Martín Salías *Enviado el:* Miércoles, 06 de Junio de 2007 12:12 p.m. *Para:* GUFA List Member *Asunto:* [GUFA] Found() Despertate, Davo!!! En VFP con DBFs, el laburo lo hace el cliente (el motor está en el cliente). Cuando hablamos de un motor externo, entonces, seeeeeeee, tiene toda la razón. Salú, /ms On 6/6/07, David Brunstein <[EMAIL PROTECTED]> wrote: > > Bueno, bueno bueno... me parece que algo muy importante quedo en el > tintero, un concepto fundamental que me parece que Martin omitio -o por lo > menos yo no lo lei... > > Cuando usas SQL queries le estas tirando el laburo al motor de base de > datos. El que hace el laburo es el SERVER y no el CLIENT. Los motores de > base de datos son "programitas" diseniados especialmente para eso, para > manipular datos, principalmente para hacer SELECT y optimizar las busquedas > con todos los recursos que tienen. Ya que estamos tambien pueden hacer > INSERT/DELETE/UPDATE, manejar transacciones, seguridad, grants de usuarios, > backups, comunicaciones, y todo el boludeo que sabemos... > > Me repito: usando SQL SELECT el laburo lo hace el motor, no el Fox, > loco. Dejemos el cliente para lo que sabe hacer que es la logica de negocio, > y al pobre motor que solo sabe manipular datos... demosle la oportunidad de > demostrar lo que puede hacer... > > Quisiera ver a Fox loopeando unos 500.000 registros para extraer un > cursor, y cualquier motor... me parace que le apuesto al motor... > > My 2 micro-cents, > Davo. > > > On 6/6/07, Oscar Zárate <[EMAIL PROTECTED]> wrote: > > > > OK, el desafio esta tomado, pero ... me vas a tener que dar hasta el > > fin de semana ... ahora no tengo mas VFP installed en mi maquina, asi > > .... dejame que lo prepare en casa ... pero te aclaro que una viene > > por el lado de trabajar con un grupo reducido de records en una tabla > > de muchos registros sin indices y esos registros estan juntos por ser > > haber sidos ingresados juntos. No tiene indices porque tiene gran > > cantidad de bulk insert, pero baja cantidad de read. > > > > Otra es actualizacion de algunos registros en una tabla de muchos > > registros donde las condiciones son muchas (mucho IF mejor para hacer > > andentro de un SCAN y mas facil de mantener el codigo para una persona > > nueva). > > > > Bueno ... me voy a poner a laburar ... sino .... voy a tener que pagar > > > > OTRA cerveza en Dic. :-) > > > > > > SaludOZ, > > > > On 6/6/07, Martín Salías <[EMAIL PROTECTED] > wrote: > > > Hola, Oz. > > > > > > Bueno, bromas aparte, mi postura no es dogmática. Fijate que dije > > que estas > > > eran mis recomendaciones, no mis normas o algo por el estilo. > > > > > > Pero de hecho, sigo sin ver los casos en que la manipulación manual > > le gane > > > al SQL. Mandame un ejemplo y lo vemos. Te anticipo que hay otras > > ventajas en > > > dejar que el motor decida en vez de optimizar a mano. > > > > > > Pensá que después de discutir con Davo, vos sos peso pluma.... > > (JAJAJA) > > > > > > Abrazo, > > > /ms > > > > > > > > > On 6/6/07, Oscar Zárate < [EMAIL PROTECTED]> wrote: > > > > OK! Te tengo donde queria :-) > > > > > > > > Tu recomendacion inicial decia: "Usar sentencias SQL para todo, en > > > > > > lugar de seek/scan" y yo no la comparto como tal, suena muy > > dogmatica > > > > (ya se que vos sos un Taliban). > > > > > > > > Yo cambiaria tu sentencia por: > > > > Si queres escribir un codigo que sea agnostico en cuanto al motor, > > usa > > > > Sentencia SQL en lugar de XBase. > > > > > > > > Yo creo que en algunos casos no hay dudas que el Select y muchas > > mas > > > > el Update o el Delete son mejores o mas claros que sus > > equivalentes > > > > XBASE, pero no es siempre. > > > > El caso tipico se da en las aplicaciones que por su alto volumen > > de > > > > Inserciones/Actualizaciones no justifica el uso de todos los > > indices > > > > que deberia tener para optimizar las busquedas. En ese caso (donde > > > > > > Rushmore va a trabajar mal con el SELECT) se puede hacer mejores > > > > cosas, sabiendo por ejemplo que queres hacer algo con los ultimos > > N > > > > registro de una table porque "hay_algo_que_hacer". > > > > > > > > Hay muchos casos en los que un SCAN es mejor que el equivalente > > SQL y > > > > es ahi donde no comparto la afirmacion. > > > > > > > > Un caso es la performance, pero para esto tengo que preparar los > > > > ejemplos donde encontre la ventaja del REPLACE en un SCAN era > > mejor > > > > que el equivalente UPDATE. > > > > > > > > No hay dudas respecto a las bondades del SQL, pero no creo que sea > > > > SIEMPRE mejor que el XBASE que se gano su lugar ahi. > > > > > > > > SaludOZ > > > > > > > > PS: Nota para el lector desprevenido: Hay una broma, dado que > > Martin > > > > no es Dogmatico, pero nos hemos acusado mutuamente de Taliban > > durante > > > > mucho tiempo. Jejeje > > > > > > > > On 6/6/07, Martín Salías < [EMAIL PROTECTED]> wrote: > > > > > Hola, OZ. > > > > > > > > > > Gracias por corregir el sys. > > > > > > > > > > ¿Porqué SQL? Por varios motivos: > > > > > > > > > > - El código es más portable a otros entornos > > > > > - Con el famoso sys podés analizar si el acceso es óptimo. A > > mano tenés > > > que > > > > > analizar la lógica vos. > > > > > - Porque a pesar de ser un lenguaje algo feo (a mi gusto) la > > intención > > > es > > > > > mucho más clara que en código de acceso a datos manual > > > > > > > > > > Para entender bien este último punto, armá a mano (con > > seek/scan) el > > > > > equivalente a un query como: > > > > > > > > > > select cliente.zona, zonas.nombre , cuenta.tipo, sum( > > cuenta.saldo ) as > > > > > acumulado ; > > > > > from cliente ; > > > > > join on cuenta on cliente.id = cuenta.id ; > > > > > join on zonas on cliente.zona = zonas.zona ; > > > > > where cliente.region = 42 ; > > > > > group by zona, nombre, tipo ; > > > > > order by acumulado desc > > > > > > > > > > La verdad no garantizo que el select esté correcto porque lo > > tiré al > > > boleo, > > > > > per cualquiera entiende la intención. Si lo hacés con loops no > > creo que > > > pase > > > > > lo mismo. Incluso con casos más simples hay diferencia. Con > > casos más > > > > > complejos (que los hay, a patadas) ni hablar... > > > > > > > > > > Saludos, > > > > > /ms > > > > > > > > > > > > > > > On 6/5/07, Oscar Zárate < [EMAIL PROTECTED]> wrote: > > > > > > Martin, si recordas mal :-) el SYS es 3054. > > > > > > > > > > > > Con respecto a "Usar sentencias SQL para todo, en lugar de > > seek/scan" > > > > > > comparto 100% si queres hacer una DAL generica, pero ... > > podrias > > > > > > explicar un poco mas largo "porque". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Martín Salías > > > www.Salias.com.ar > > > Microsoft MVP - Agile Alliance Member > > > > > > > -- > ======================= > David Brunstein > > Java/PB/VFP Developer > Winnipeg, MB > Canada > > Before I speak, I have something important to say. > Antes de dar mi discurso, tengo algo importante que decir. > Antes de dar meu discurso, tenho algo importante para dizer. > G.M. > -- Martín Salías www.Salias.com.ar Agile Alliance Member - Microsoft MVP
-- Martín Salías www.Salias.com.ar Agile Alliance Member - Microsoft MVP
