Entonces qué sentido tiene crear relaciones permanentes en VFP?..
655 views
Skip to first unread message
Fox Learner
Jun 25, 2012, 11:14:14 AM6/25/12
to Comunidad de Visual Foxpro en Español
Leo en el manual del programador que las relaciones temporales creadas
con SET RELATION hacen que "los punteros" se muevan paralelamente en
tablas "relacionadas".
Segun el manual, las relaciones permanentes se crean con el asistente
de BD de fox, mediante unir con lineas los indices de cada tabla.
Luego viene una nota que dice algo así: Las relaciones permanentes no
hace que coincidan los punteros en las tablas relacionadas, por lo que
debe debe aprender a usar tambien las relaciones temporales
dependiendo de sus necesidades.
Hasta donde entiendo, en MySql las relaciones entre tablas se usan
para "exigir" que por ejemplo al momento que el sistema intenta borrar
un registro que tiene relacion con otra tabla, el gestor diría algo
como que no se puede hacer eso porque afectaria la relacion entre
tablas o la "Integridad Referencial(IR).
Veo tambien que no son tan necesarias las relaciones mientras exista
un "campo común" que pueda hacer la mezcla de datos entre tablas como
con un join de los selects.
Entonces cual es la utilidad real de las "relaciones permanentes" en
VFP?..
Perdon por la ignorancia, pero no logro captarlo.
Saludos!
con SET RELATION hacen que "los punteros" se muevan paralelamente en
tablas "relacionadas".
Segun el manual, las relaciones permanentes se crean con el asistente
de BD de fox, mediante unir con lineas los indices de cada tabla.
Luego viene una nota que dice algo así: Las relaciones permanentes no
hace que coincidan los punteros en las tablas relacionadas, por lo que
debe debe aprender a usar tambien las relaciones temporales
dependiendo de sus necesidades.
Hasta donde entiendo, en MySql las relaciones entre tablas se usan
para "exigir" que por ejemplo al momento que el sistema intenta borrar
un registro que tiene relacion con otra tabla, el gestor diría algo
como que no se puede hacer eso porque afectaria la relacion entre
tablas o la "Integridad Referencial(IR).
Veo tambien que no son tan necesarias las relaciones mientras exista
un "campo común" que pueda hacer la mezcla de datos entre tablas como
con un join de los selects.
Entonces cual es la utilidad real de las "relaciones permanentes" en
VFP?..
Perdon por la ignorancia, pero no logro captarlo.
Saludos!
Carlos Miguel FARIAS
Jun 25, 2012, 11:30:03 AM6/25/12
to publice...@googlegroups.com
Una cosa es la relaciòn creada con el SET RELATION, que es temporal y activa, o sea, que una vez establecida esa relaciòn, los punteros se mueven en paralelo (mantienen el match), pero al cerrar las tablas, eso se pierde, ademas funciona con tablas libres.
La relaciòn en el diseñador, sirve cuando manejas integridad referencial desde el mismo diseñador de bd, para que pueda saber como enganchar las tablas.
Ademas esa relaciòn te la muestra el entorno de datos al diseñar formularios.
Creo que el match de archivos no se produce automáticamente.
Saludos: Miguel, La Pampa (RA)
La relaciòn en el diseñador, sirve cuando manejas integridad referencial desde el mismo diseñador de bd, para que pueda saber como enganchar las tablas.
Ademas esa relaciòn te la muestra el entorno de datos al diseñar formularios.
Creo que el match de archivos no se produce automáticamente.
Saludos: Miguel, La Pampa (RA)
mpulla
Jun 25, 2012, 11:43:37 AM6/25/12
to publice...@googlegroups.com
La integridad referencial o relaciones permanentes en VFP, MySql, Sql Server, Oracle y demas gestores de datos tienen la misma funcionalidad.
El set relation en VFP, te crea una relacion temporal, si en tu formulario eliminas un registro de la tabla padre no saldra ningun mensaje "si esque la tabla no tendrian integridad relacional" a nivel de DB y si tendrian integridad relacional el mensaje de error seria "a nivel de la db no del set relation".
<<Veo tambien que no son tan necesarias las relaciones mientras exista
"Integridad referencial indispensable"
Saludos
Mauricio.
Geovanny Quirós Castillo
Jun 25, 2012, 12:43:20 PM6/25/12
to publice...@googlegroups.com
Hola Fox Learner,
Anteriormente te hab�a indicado que esas son t�cnicas de programaci�n que ya
no se usan, bueno; puede haber por ah� uno que otro programador de Visual
Fox que sigue desarrollando utilizando t�cnicas obsoletas, como el APPEND
BLANK, REPLACE... y el SET RELATION.
Si quieres un consejo te lo doy: No pierdas el tiempo tratando de entender
para que sirve el SET RELATION y mucho menos comparando estas relaciones con
las que se cren en motores de bases de datos de verdad, como ya te lo dijo
Carlos Miguel.
Si quieres usar tablas libres, usalas pero utilizando los comandos de SQL.
Saludos
-----Mensaje original-----
From: Fox Learner
Sent: Monday, June 25, 2012 9:14 AM
To: Comunidad de Visual Foxpro en Espa�ol
Subject: [vfp] Entonces qu� sentido tiene crear relaciones permanentes en
VFP?..
Leo en el manual del programador que las relaciones temporales creadas
con SET RELATION hacen que "los punteros" se muevan paralelamente en
tablas "relacionadas".
Segun el manual, las relaciones permanentes se crean con el asistente
de BD de fox, mediante unir con lineas los indices de cada tabla.
Luego viene una nota que dice algo as�: Las relaciones permanentes no
Anteriormente te hab�a indicado que esas son t�cnicas de programaci�n que ya
no se usan, bueno; puede haber por ah� uno que otro programador de Visual
Fox que sigue desarrollando utilizando t�cnicas obsoletas, como el APPEND
BLANK, REPLACE... y el SET RELATION.
Si quieres un consejo te lo doy: No pierdas el tiempo tratando de entender
para que sirve el SET RELATION y mucho menos comparando estas relaciones con
las que se cren en motores de bases de datos de verdad, como ya te lo dijo
Carlos Miguel.
Si quieres usar tablas libres, usalas pero utilizando los comandos de SQL.
Saludos
-----Mensaje original-----
From: Fox Learner
Sent: Monday, June 25, 2012 9:14 AM
To: Comunidad de Visual Foxpro en Espa�ol
Subject: [vfp] Entonces qu� sentido tiene crear relaciones permanentes en
VFP?..
Leo en el manual del programador que las relaciones temporales creadas
con SET RELATION hacen que "los punteros" se muevan paralelamente en
tablas "relacionadas".
Segun el manual, las relaciones permanentes se crean con el asistente
de BD de fox, mediante unir con lineas los indices de cada tabla.
hace que coincidan los punteros en las tablas relacionadas, por lo que
debe debe aprender a usar tambien las relaciones temporales
dependiendo de sus necesidades.
Hasta donde entiendo, en MySql las relaciones entre tablas se usan
para "exigir" que por ejemplo al momento que el sistema intenta borrar
un registro que tiene relacion con otra tabla, el gestor dir�a algo
debe debe aprender a usar tambien las relaciones temporales
dependiendo de sus necesidades.
Hasta donde entiendo, en MySql las relaciones entre tablas se usan
para "exigir" que por ejemplo al momento que el sistema intenta borrar
como que no se puede hacer eso porque afectaria la relacion entre
tablas o la "Integridad Referencial(IR).
Veo tambien que no son tan necesarias las relaciones mientras exista
un "campo com�n" que pueda hacer la mezcla de datos entre tablas como
tablas o la "Integridad Referencial(IR).
Veo tambien que no son tan necesarias las relaciones mientras exista
Fox Learner
Jun 25, 2012, 8:53:58 PM6/25/12
to Comunidad de Visual Foxpro en Español
Geovanny,
Eso si ya lo capté.
SET RELATION=Relaciones Temporales=Tecnica Obsoleta... Como ya me
habías indicado.
Se me recomendó usar los joins de los selects en lugar del set
relation.
Lo que no entiendo es las "Relaciones permanentes", aquellas que se
crean poniendo una linea entre los campos indexados de las tablas.
O mas bien, el manual es el que me confunde al decir que "las
permanentes" no hacen que coincidan los punteros y que debo usar
tambien las temporales.
Ahora bien, con el comentario del maestro Carlos Miguel y Mauricio, se
me aclaró que eso en VFP se refiere a lo mismo que ocurre en los
gestores como MySql, es decir, las relaciones permanentes son para
exigir la integridad referencial, como cuando intentas borrar datos
que tienen una "relacion" con otros datos que los hacen comprensibles.
Bueno, creo que ya medio entendí el punto .. Creo que eso de "los
punteros" NO automaticos es lo que me confunde.
Lo de los tipos de relaciones lo entiendo bien eso de:
1:1 uno a uno, cuando a cada registro de una tabla corresponde un
registro de otra tabla. De hecho el manual recomienda "analizar" si
sería conveniente "unificar" este tipo de relaciones en una sola
tabla.
1:m uno a muchos, es la normal, la tipo maestro-detalle, donde a un
registro de una tabla corresponden muchos de otra.
m:n muchos a muchos, cuando a un registro de una tabla corresponden
muchos de otra, pero a uno de esa otra corresponden muchos de la
primera. El manual dice que esto debe solucionarse creando una tabla
intermedia que "combine" ambos indices de cada tabla en una sola tabla
intermedia, donde el indice de esa tabla intermedia seria un campo
compuesto por dos claves de indice.
Saludos!
Eso si ya lo capté.
SET RELATION=Relaciones Temporales=Tecnica Obsoleta... Como ya me
habías indicado.
Se me recomendó usar los joins de los selects en lugar del set
relation.
Lo que no entiendo es las "Relaciones permanentes", aquellas que se
crean poniendo una linea entre los campos indexados de las tablas.
O mas bien, el manual es el que me confunde al decir que "las
permanentes" no hacen que coincidan los punteros y que debo usar
tambien las temporales.
Ahora bien, con el comentario del maestro Carlos Miguel y Mauricio, se
me aclaró que eso en VFP se refiere a lo mismo que ocurre en los
gestores como MySql, es decir, las relaciones permanentes son para
exigir la integridad referencial, como cuando intentas borrar datos
que tienen una "relacion" con otros datos que los hacen comprensibles.
Bueno, creo que ya medio entendí el punto .. Creo que eso de "los
punteros" NO automaticos es lo que me confunde.
Lo de los tipos de relaciones lo entiendo bien eso de:
1:1 uno a uno, cuando a cada registro de una tabla corresponde un
registro de otra tabla. De hecho el manual recomienda "analizar" si
sería conveniente "unificar" este tipo de relaciones en una sola
tabla.
1:m uno a muchos, es la normal, la tipo maestro-detalle, donde a un
registro de una tabla corresponden muchos de otra.
m:n muchos a muchos, cuando a un registro de una tabla corresponden
muchos de otra, pero a uno de esa otra corresponden muchos de la
primera. El manual dice que esto debe solucionarse creando una tabla
intermedia que "combine" ambos indices de cada tabla en una sola tabla
intermedia, donde el indice de esa tabla intermedia seria un campo
compuesto por dos claves de indice.
Saludos!
Fox Learner *
Jun 25, 2012, 10:32:39 PM6/25/12
to publice...@googlegroups.com
Gracias Marco,
La mayoría de los compañeros del grupo dicen que SET RELATION puede ser sustituido por Selects.
Si alguien dice que el Set Relation es obsoleto, debe ser él quien te lo aclare. Yo no sabría si lo es o no, pero seguro que nos interesaría saber por que se afirma eso..
Saludos!
Marco Plaza
Jun 25, 2012, 10:22:00 PM6/25/12
to Comunidad de Visual Foxpro en Español
FoxLearner set relation es un comando indispensable. No se usa para el
diseño de la BD, sino para el manejo de cursores y operaciones
importantes en vfp.
Debes usarlo cuando por ejemplo:
-deseas crear reportes con multiples bandas
-quieres hacer un grid de facturas con un grid de detalle
-necesitas crear xml con tablas anidadas usando el xmladapter
-necesitas crear vistas de tablas locales relacionadas sin crear
cursores temporales
Marco
diseño de la BD, sino para el manejo de cursores y operaciones
importantes en vfp.
Debes usarlo cuando por ejemplo:
-deseas crear reportes con multiples bandas
-quieres hacer un grid de facturas con un grid de detalle
-necesitas crear xml con tablas anidadas usando el xmladapter
-necesitas crear vistas de tablas locales relacionadas sin crear
cursores temporales
Marco
Edgar Acevedo
Jun 26, 2012, 1:03:23 AM6/26/12
to publice...@googlegroups.com
Lo que pasa es que lo que ahora conoces como "Visual Foxpro 9" ha venido evolucionando desde finales de los 80's de un producto llamado "FoxBase" (que luego evolucionó en "FoxBase+").
Cuando salió Foxpro 1.0 para DOS, tenía la generosa hablidad de poder usar el SET RELATION en relaciones de 1 a 1, de 1 a varios y en forma de cascada.
Luego de varios años y de varias versiones mas del poderoso "zorro", se llegó a agregar y mejorar sentencias SQL para obtener los mismos resultados, solo que de otra forma y con otros comandos.
Para los viejos programadores (como tu servidor) que venimos de la era del SET RELATION, nos acostumbramos a usarlo de tal modo que a la mayoría no nos ha interesado sustiturilo por sentencias SQL. La "gracia" esa de poder establecer relaciones permanentes desde el "Diseñador de Base de Datos" es simplemente otra "maravilla" puesta a disposición de los programadores de VFP para que puedan utilizar integridad referencial y otro tipo de cosas desde el diseño mismo de la Base de Datos.
Aunque es "muy bonito" y elegante lo que habla el manual de establecer relaciones permanentes desde la base de datos, yo sigo utilizando los SET RELATION de manera temporal. Los armo cuando los necesito y luego los desarmo cuando ya no los necesito. Es cuestión de "estilos de programación". Hay quienes manejan prácticamente todo desde la "Integridad Referncial", los "Procedimientos Almacenados" y los "Triggers". Otros manejan todo esto mediante clases de código (visuales y no visuales) y otros (los mas viejos como yo) ya lo hemos venido manejando por años utilizando procedimientos parametrizados.
VFP a manera de ser "muy útil" te presenta varias formas de lograr una misma cosa y esto a veces se puede prestar a confusión o malas interpretaciones. El objetivo de los diseñadores de VFP es ofrecerte diferentes formas de hacer una cosa para que utilices aquella con la que te sientas mas cómodo de usar. Es como si para aflojar una tuerca, VFP te ofreciera una tenaza, un alicate, una llave de copa, una llave de corona, una llave simple, una llave inglesa o un cangrejo. Tu utilizarás aquella con la que sientas "mas lógica" y "rápida" de implementar la cosa y que así mismo corra en el menor tiempo de ejecución posible.
Que las diferentes maneras de hacer algo en VFP no te confundan. Si tienes tiempo pruébalas todas y opta por aquella que te resulte mas simple de implementar y que a la vez notes que corra mas eficientemente en la aplicación que estas desarrollando. No te atormentes pensando ¿ habré utilizado la mejor manera de hacerlo ? porque la intención de la diversidad de formas de VFP NO ES atormentarte con dudas existenciales como esa sino mas bien servirte de mil y un maneras a un mismo propósito para que utilices aquella con la que "según tu criterio" (y no el de otro programador que no esta metido en tu pellejo ni usando tus zapatos) es la que mejor te resulte.
Nunca habrá "algún listo" que te diga que tal o cual cosa "se hace mejor de este modo", de la misma forma que nunca faltará alguien que te diga que cierta marca de automovil es mejor que otra, o que las rubias son mas sensuales que las trigueñas o que el Kung-Fu es mas efectivo que el Aiki-Do o que la Jenifer Aniston esta mas buena que la Cameron Diaz, etc, etc, etc
Salu2,
Edgar
Cuando salió Foxpro 1.0 para DOS, tenía la generosa hablidad de poder usar el SET RELATION en relaciones de 1 a 1, de 1 a varios y en forma de cascada.
Luego de varios años y de varias versiones mas del poderoso "zorro", se llegó a agregar y mejorar sentencias SQL para obtener los mismos resultados, solo que de otra forma y con otros comandos.
Para los viejos programadores (como tu servidor) que venimos de la era del SET RELATION, nos acostumbramos a usarlo de tal modo que a la mayoría no nos ha interesado sustiturilo por sentencias SQL. La "gracia" esa de poder establecer relaciones permanentes desde el "Diseñador de Base de Datos" es simplemente otra "maravilla" puesta a disposición de los programadores de VFP para que puedan utilizar integridad referencial y otro tipo de cosas desde el diseño mismo de la Base de Datos.
Aunque es "muy bonito" y elegante lo que habla el manual de establecer relaciones permanentes desde la base de datos, yo sigo utilizando los SET RELATION de manera temporal. Los armo cuando los necesito y luego los desarmo cuando ya no los necesito. Es cuestión de "estilos de programación". Hay quienes manejan prácticamente todo desde la "Integridad Referncial", los "Procedimientos Almacenados" y los "Triggers". Otros manejan todo esto mediante clases de código (visuales y no visuales) y otros (los mas viejos como yo) ya lo hemos venido manejando por años utilizando procedimientos parametrizados.
VFP a manera de ser "muy útil" te presenta varias formas de lograr una misma cosa y esto a veces se puede prestar a confusión o malas interpretaciones. El objetivo de los diseñadores de VFP es ofrecerte diferentes formas de hacer una cosa para que utilices aquella con la que te sientas mas cómodo de usar. Es como si para aflojar una tuerca, VFP te ofreciera una tenaza, un alicate, una llave de copa, una llave de corona, una llave simple, una llave inglesa o un cangrejo. Tu utilizarás aquella con la que sientas "mas lógica" y "rápida" de implementar la cosa y que así mismo corra en el menor tiempo de ejecución posible.
Que las diferentes maneras de hacer algo en VFP no te confundan. Si tienes tiempo pruébalas todas y opta por aquella que te resulte mas simple de implementar y que a la vez notes que corra mas eficientemente en la aplicación que estas desarrollando. No te atormentes pensando ¿ habré utilizado la mejor manera de hacerlo ? porque la intención de la diversidad de formas de VFP NO ES atormentarte con dudas existenciales como esa sino mas bien servirte de mil y un maneras a un mismo propósito para que utilices aquella con la que "según tu criterio" (y no el de otro programador que no esta metido en tu pellejo ni usando tus zapatos) es la que mejor te resulte.
Nunca habrá "algún listo" que te diga que tal o cual cosa "se hace mejor de este modo", de la misma forma que nunca faltará alguien que te diga que cierta marca de automovil es mejor que otra, o que las rubias son mas sensuales que las trigueñas o que el Kung-Fu es mas efectivo que el Aiki-Do o que la Jenifer Aniston esta mas buena que la Cameron Diaz, etc, etc, etc
Salu2,
Edgar
Guillermo Gimenez
Jun 26, 2012, 2:14:58 AM6/26/12
to publice...@googlegroups.com
| Si acaso sirve de cuento de una noche fría (como la de hoy en Paraguay)... para un sistema hice todo el "análisis y diseño" de la BD con relaciones, integridad referencial, pk's y fk's (obviamente) y lo implementamos en un dbc (con tablas dbf)... todo era muuuuuy bonito... pocas tablas.. menos de 50... algunos datos (mas de 300.000 la tabla mas grande)... cuando corriamos el programa y cargabamos un nuevo registro (en una tablas con varias "referencias" que tendrian que ser "integrales"), al hacer click en el boton "Grabar" tardaba mas de 20 segundos (en las maquinas de la red).... y obviamente los muchachos "me vinieron al humo" (se quejaron)... suspendi todas las fk's y fiu! (algo que pasa rapido)... el sistema VOLO!!... Lo que
tenemos que entender... es que el DBC genera scrips (procedimientos) en una especie de PRG que esta dentro del DBC, donde se realizan los controles de integridad referencial, esos procedimientos se ejecutan en Sesion de Datos donde se estan modificando los datos (NO EN EL SERVIDOR)... cuando son pocos datos y usados localmente.. todo lindo... pero cuando crecen las tablas y el sistema esta siendo usado en red... todos se ponen muuuuy nerviosos.... por lo que mi humilde recomendación es evitar las "relaciones permanentes"...y tener todos los controles de ingreso de datos en la aplicacion.... y buscar la manera de esconder las tablas (archivos físicos .dbf) de los curiosos... es mi experiencia... |
Luis Maria Guayan
Jun 26, 2012, 8:55:05 AM6/26/12
to publice...@googlegroups.com
Personalmente no
creo que SET RELATION sea un comando "indispensable". En mis
aplicaciones no uso SET RELATION y todo lo puedes lograr con una
sentencia SELECT SQL adecuada.
Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________
Luis Maria Guayan
Jun 26, 2012, 8:57:57 AM6/26/12
to publice...@googlegroups.com
Muy buen resumen
Edgar, así es VFP se ajusta al gusto de cada uno ;-)
Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________
Miguel Canchas
Jun 26, 2012, 9:42:06 AM6/26/12
to publice...@googlegroups.com
Respuesta sencilla: viene por compatibilidad con las versiones anteriores…
MK
De:
publice...@googlegroups.com [mailto:publice...@googlegroups.com] En
nombre de Edgar Acevedo
Enviado el: martes, 26 de junio de 2012 12:03 a.m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Entonces qué sentido tiene crear relaciones
permanentes en VFP?..
Lo que pasa es que lo que ahora conoces como "Visual Foxpro 9" ha venido evolucionando desde finales de los 80's de un producto llamado "FoxBase" (que luego evolucionó en "FoxBase+").
Fox Learner
Jun 26, 2012, 9:44:12 AM6/26/12
to Comunidad de Visual Foxpro en Español
Edgar... Gracias por el consejo. Me quedo con Scarlett Johansson o
Megan Fox... jeje
Si comprendo eso de que el VFP viene desde la época Dbase (Incluso usé
Dbase III Plus y Clipper Summer 87 y 5.2 para fines didácticos).
Entiendo que por ello siga teniendo muchos comandos que conservan la
compatibilidad hacia atrás.
Pienso que los comandos o funciones "viejas" no son malas.
Solo busco los métodos un tanto "modernos" o standard y cómodos, de
tal forma que lo que pueda aprender con VFP me prepare para lo que
venga después del VFP.
Sin embargo, como se dijo, yo aun uso tablas libres y el append blank,
el replace y otros comandos, porque les tengo confianza.
En cuanto le voy teniendo confianza a lo que "ya entiendo bien", lo
implemento sin muchos problemas. Es por eso que "suelo quebrarme la
cabeza" examinando ciertos métodos antes de elegir el que me parezca
mas razonable para mis circunstancias. Prefiero darme dolores de
cabeza "antes" de elegir cierto método, que una vez que lo tenga
implementado y el cliente me llame desesperado sin saber que hacer.
En este caso, creo que mi elección serán los selects.
Guille,
Eres el famoso Guille, de la página del Guille? jeje
Saludos!
Megan Fox... jeje
Si comprendo eso de que el VFP viene desde la época Dbase (Incluso usé
Dbase III Plus y Clipper Summer 87 y 5.2 para fines didácticos).
Entiendo que por ello siga teniendo muchos comandos que conservan la
compatibilidad hacia atrás.
Pienso que los comandos o funciones "viejas" no son malas.
Solo busco los métodos un tanto "modernos" o standard y cómodos, de
tal forma que lo que pueda aprender con VFP me prepare para lo que
venga después del VFP.
Sin embargo, como se dijo, yo aun uso tablas libres y el append blank,
el replace y otros comandos, porque les tengo confianza.
En cuanto le voy teniendo confianza a lo que "ya entiendo bien", lo
implemento sin muchos problemas. Es por eso que "suelo quebrarme la
cabeza" examinando ciertos métodos antes de elegir el que me parezca
mas razonable para mis circunstancias. Prefiero darme dolores de
cabeza "antes" de elegir cierto método, que una vez que lo tenga
implementado y el cliente me llame desesperado sin saber que hacer.
En este caso, creo que mi elección serán los selects.
Guille,
Eres el famoso Guille, de la página del Guille? jeje
Saludos!
Geovanny Quirós Castillo
Jun 26, 2012, 9:55:49 AM6/26/12
to publice...@googlegroups.com
Te aclaro mi punto de vista, esta es mi opinión personal pero algun
otro compañero puede pensar diferente y aportar argumentos validos.
En mi caso usar el Set Relation es algo que pasó a la historia hace ya
mucho tiempo.
En su momento fue una herramienta muy util pero cuando trabajas con motores
de bases de datos ese tipo de sentencias queda sobrando.
Busquemos la logica de este asunto:
Si estas desarrollando una aplicación con Vfox + Sql Server o MySql o
Oracle o Firebird o lo que sea; no te vas a traer los registros de la BD a
cursores de fox y les vas a crear indices y luego vas a crearles las relaciones,
eso no tiene sentido, si quieres mostrar un maestro – detalle (Ejemplo una
factura, un asiento, etc ) eso lo solventas a lo mucho con 2 selects o con un SP
que lo haga todo.
Por eso creo que Set Relation está obsoleto, espero haberte aclarado.
Saludos
Luis Mata
Jun 26, 2012, 9:59:24 AM6/26/12
to publice...@googlegroups.com
Increíble aun evaluando las DBF tecnología desfasada de mas 50 años de antigüedad, y aplicando integridad referencial.........Una base de datos que no trabaja con integridad referencial, a la larga se hace pedazos y poco confiable en el manejo de información. Pero si obligas a tu base de datos que SI o SI te pida ese dato y sin eso no continuas aseguras la integridad de la información. Al menos la experiencia que he tenido en el manejo de esta tecnología en SQL Server 2008 ahora testeando el 2012, ha sido espectacular, me ha reducido la programación casi al 60%, mínimas validaciones mediante código ya que todo lo haces en un SP capturando los errores y el mensaje es bien claro pidiéndote el datos que falta.
Hoy en día comparando lo que use anteriormente tablas libres, realmente es incomparable el uso de esta nueva forma. Anteriormente había huecos por todos lados:
- Un cliente a pesar de tener ventas asociadas lo podías eliminar, o de lo contrarios debías crear una rutina de validación, cosa que ya no es necesario con las IR.
- Una proforma la podías anular a pesar que ya tenia FAC, BOL.. etc asociado, o de lo contrarios debías crear una rutina de validación, cosa que ya no es necesario con las IR.
- Los productos, proveedores... etc de la misma manera.
- Datos huérfanos por todos lados
Y para controlar eso y muchas cosas mas te llenabas de códigos de validación por todos lados, cosa que con la IR ya no es necesaria, pero si quieres las puedes hacer, pero para que? si la misma BD te lo valida.
E integridad Referencial no puede existir sin relaciones permanentes, lamentablemente después de haberte dicho esto te parece valido tu consejo de no usarlas relaciones permanentes. y la velocidad no es problema para mi ya que es muy estable. Lo que yo recomendaria recordando viejos tiempos es JAMAS usar sesion de datos.
A menos que sea exclusivo para DBF y NO como un concepto general en el manejo de datos.
Luis Maria Guayan
Jun 26, 2012, 10:36:37 AM6/26/12
to publice...@googlegroups.com
El 26/06/2012 10:44, Fox Learner
escribió:
Guille, Eres el famoso Guille, de la página del Guille? jeje
Fox Learner
Jun 26, 2012, 11:13:44 AM6/26/12
to Comunidad de Visual Foxpro en Español
Ok. Gracias por la aclaración Maestro Luis Maria.
Es que no me he registrado en el guille porque al parecer mandan
publicidad al correo.
No lo se..
Es que no me he registrado en el guille porque al parecer mandan
publicidad al correo.
No lo se..
Reply all
Reply to author
Forward
0 new messages