¿ Preferible el INSERT TO al APPEND BLANK ?

[arti...@gmail.com]

¿ Es preferible usar el INSERT TO en lugar del APPEND BLANK ?, ¿ Qué ventajas tiene ?

[Fernando D. Bozzo]

APPEND BLANK no bloquea el registro, por lo que apenas lo creás otro usuario de la red lo puede usar, lo que puede causar pérdida o corrupción de datos

INSERT-SQL bloquea y reemplaza datos a la vez, lo que es más rápido y más seguro.


Saludos.-

[allan...@hotmail.com]

Con el INSERT en una sola instruccion. Considero alli la ventaja.

Ahora bien depende la circunstancia del evento.

Saludos

Allan. R. Acuña.

Enviado por Outlook para Android

[Carlos Miguel FARIAS]

El INSERT es en todo sentido superior al APPEND BLANK o sea, es todo ventajas.

A nivel código: MENOS CANTIDAD DE CÓDIGO.

un insert utiliza una sola instrucción para insertar un registro en la tabla y ponerle los datos correspondientes.

un append blank require, posicionarte en la tabla donde agregas el append blank y luego uno o más replace para poner los datos donde corresponda.

ejemplo:

INSERT INTO tuTablaDestino (campo1, campo2, ... campoN) VALUES (variable1, variable 2, ... variableN)

contra

SELECT tuTablaDestino

APPEND BLANK

REPLACE campo1 WITH variable1, campo2 WITH variable2, ... campoN WITH variableN

A nivel de procesamiento: MENOR PROBABILIDAD DE CONFLICTOS MULTIUSUARIOS.

En un entorno multiusuario, si 2 o más usuarios hacen un append blank en una tabla concurrentemente, va a dar conflicto de clave primaria o candidata duplicada, y inconsistencia con las UNIQUE, eso no pasa con INSERT

a nivel de compatibilidad: COMPATIBILIDAD DE PASAR A UN SGBD

append blank y replace solo son aplicable con tablas nativas.

insert es aplicable además con SGBD no nativos (solo debes "encapsular" el código con un SQLExec.

Saludos: Miguel, La Pampa (RA)

[Rick C. Hodgin]

Por Google Translate:  APPEND BLANK obras correctamente en entorno multiusuario en Visual FreePro. Se lleva a cabo el bloqueo.

Saludos cordiales,
Rick C. Hodgin

English:  APPEND BLANK works correctly in multi-user environment in Visual FreePro.  It performs the lock.

[arti...@gmail.com]

Bueno y para cuando empezará a estar disponible Visual FreePro ?

[Carton Jeston (9.0.0.7423)]

Estamos hablando cuando trabajas directamente sobre la base de datos. ¿no?

¿esta circustancia se da tambien al añadir sobre un cursor?

Lo digo porque esta pregunta la he visto varias veces con diferente respuesta, asi que en cursores uso append blank pero cuando se trata de base de datos o tablas directamente insert.

[arti...@gmail.com]

Si por supuesto, hablo de base de datos nativa

[Fernando D. Bozzo]

La respuesta es válida tanto para tabla como para cursor, la única diferencia es que en un cursor el tema del bloqueo no importa porque es exclusivo del usuario, pero todas las demás ventajas siguen aplicando.

Estos temas hay que pensarlos en términos de "accesos a disco", siempre 1 acceso a disco (INSERT-SQL) va a ser más rápido que (mínimo) 2 accesos al disco (APPEND BLANK + REPLACE), y si encima agregamos la mala práctica de hacer 1 replace por campo, entonces la cantidad de accesos a disco para los REPLACE pueden ser un montón, y como sabemos, cada acceso a disco implica un tiempo de búsqueda (seek-time) + un tiempo de escritura.

Si se programa siempre como si trabajáramos en el medio más lento (recuerden los antiguos diskettes lo que era...), lo que se obtiene es siempre los mejores tiempos, y la performance del sistema siempre está dada por la suma de todas las performances da cada módulo y de cada instrucción.

Es parte de una metodología de trabajo donde siempre tenés los mejores tiempos.

Como anécdota (reciente) te puedo comentar que estuve reemplazando algunos módulos de proceso de datos antiguos (época del VFP5/6) donde la gente que los programó no tenía idea de nada de esto, y mucho menos de Rushmore. El tema es que habían hecho los módulos enfocados "en el registro", por lo que los procesaban de 1 en 1 en un SCAN o un DO WHILE aplicando una cierta lógica para hacer los reemplazos. Analizando los módulos entendí el tipo de actualización que querían hacer y los sustituí por un grupo de consultas, actualizaciones e inserciones SQL, pasando en uno de los módulos de tardar 2 horas a tardar menos de 50 segundos.

Como te digo, no importa si vas a trabajar con poca información o con mucha, siempre hay que hacerlo de la forma más óptima y pensando en la posibilidad de crecimiento de los datos. Muchos comienzan con desarrollos para tablas de 1000 registros y a los pocos meses o años llegan al millón de registros con problemas de velocidad por no haber optimizado desde el principio.

Saludos.-

[Carlos Miguel FARIAS]

Completando lo de accesos al disco de Fernando, y que omití en mi primer post.

Si la tabla tiene indices, un insert hace una actualización de disco por indice estructural (+ otros que pudiera haber).

Si usas append blank, se hacen dos actualizaciones, una la momento del append blank y otra al momento de los replace.

Aunque se esté trabajando con un cursor, donde no hay problemas de bloqueo, tengan en cuenta que los cursores y sus indices usan archivos temporales, muy rara vez quedan en buffer de memoria (del S.O.).

Tengan en cuenta que cuando se inserta un registro y este afecta un indice, el indice es un arbol B+, con suerte la nueva clave puede caer dentro de un nodo con espacio (implica al menos dos accesos al disco, más los requeridos para búsqueda) pero si el nodo correspondiente esta lleno, hay un split de indice y eso "explota". Con un append blank, eso explota al cuadrado.

O sea APPEND BLANK puaj!!!

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe y eliminen los Append Blank de sus aplicaciones

[Victor Espina]

Hay otras consideraciones tambien.  Si la tabla tiene un UDPATE TRIGGER, entiendo que este se ejecuta una por vez por cada REPLACE sobre el registro, por lo que habria que evitar usar multiples REPLACE para llenar los dato del registro.  Adicionalmente, en una reciente conversacion en Foxite se indico que algunos casos de desbordamiento podrian no ser reportados si se usa INSERT en lugar de APPEND BLANK-REPLACE.

En mi caso particular, uso INSERT siempre que pueda.

Saludos

Victor

[Rick C. Hodgin]

Por Google Translate:  Será un tiempo. Está sólo a mí trabajando en las principales piezas del motor de base de datos, y el compilador. Mi tiempo no es tan libre este año como lo ha sido en el pasado. Pero, sigo. Despacio.

Saludos cordiales,
Rick C. Hodgin

English:  It will be a while.  It is only me working on the main database engine parts, and the compiler.  My time is not as free this year as it has been in the past.  But, I am continuing.  Slowly.

[mapner]

La única observación a INSERT que en realidad es una crítica al diseño de lenguaje SQL es que no han hecho sintaxis similares entre INSERT y UPDATE.

UPDATE es más práctico en cuanto a que dispone más legiblemente el par CAMPO = VALOR , ... en cambio INSERT lo hace por lista posicional (CAMPO1, CAMPO2, CAMPO3, ...) VALUES (VALOR1, VALOR2, VALOR3...)  ... esto en un esquema con gran cantidad de campos implica cierto trastorno. En VFP (y en otros lenguajes) se puede hacer una función (como lo hacen los ORM) para que luego se genere el SQL INSERT final...

Saludos

[Fernando D. Bozzo]

Yo sin embargo lo veo al revés, creo que hubiera sido mejor hacer que el UPDATE use el esquema de actualización del INSERT: (campo1, campo2, campo3) VALUES (val1, val2, val3), ya que eso creo que hubiera incluso facilitado el hecho de actualizar desde un SELECT-SQL, tal como ocurre con el INSERT.

En el caso contrario (INSERT usando sintaxis de UPDATE), sería más compleja la inserción desde un SELECT-SQL.

[mapner]

Ok, ventajas y desventajas ... lo de actualizar desde un SELECT-SQL está bueno ... pero en un INSERT con 30 campos o más, el par CAMPO = VALOR no es muy legible a nivel de código... Ej.: si tenemos diez campos numéricos seguidos y erróneamente alteramos el orden de sus valores de reemplazo el problema no se distingue a simple vista... por eso... ventajas y desventajas

[Fernando D. Bozzo]

En eso tenés razón, más de una vez me comí algún parámetro o puse algún valor invertido con otro campo que no era :)

[mapner]

Por eso los ORM hacen una sintaxis campo a campo más cercana al lenguaje OOP de implementación y luego internamente generan la instrucción SQL que corresponde... 

Una cosa muy buena que tenía Clipper 5.x es que el lenguaje permitía crear "comandos definidos por el usuario" ... uno podía inventar un comando por ej: XREPLACE ... y disponía en que instrucciones finales se debía convertir ese comando...ventajas y desventajas... :) 

[arti...@gmail.com]

No se puede tener todo en la vida con respecto al INSERT (campo1,campo2..)..El único inconveniente que le veo es ese, si tienes que actualizar 30 o 40 campos de una vez, un fallo te puede a costar la salud mental.. Yo ya he modificado la aplicación con el INSERT, me funciona pero no he podido probarlo en el cliente...

[Víctor Hugo Espínola Domínguez]

Ese inconveniente se soluciona trabajando en el formulario con un cursor o un objeto, si los datos los tienes en un objeto la sintaxis a usar es INSERT INTO <tabla> FROM NAME <objeto>. Si los datos lo manejas mediante un cursor entonces se puede escribir una función que genere el INSERT y esta función es aplicable a cualquier tabla, hay un ejemplo en FoxyDb de Antonio Meza.

Saludos,

Víctor.

Lambaré - Paraguay.

 

[Fernando D. Bozzo]

Cierto Víctor, por eso yo siempre que puedo uso la sintaxis del INSERT-SQL FROM NAME objeto, ya que justamente es genial poder trabajar el objeto en memoria y luego enviarlo directamente a la BDD.

[mapner]

Si, muy buena la solución de INSERT INTO <tabla> FROM NAME <objeto>, pero la sentencia SQL-INSERT va más allá del uso interno de VFP, por ejemplo en otros motores de BD como MySQL, MS-SQL,Firebird, ...De hecho en Firebird se dispone de un comando llamado UPDATE OR INSERT donde si el motor detecta que la PK informada no existe genera un INSERT, sino, un genera un UPDATE ... pero con campos y valores posicionales :(

[Víctor Hugo Espínola Domínguez]

Mediante cursor adapter  INSERT INTO <oCurAda>.Alias FROM NAME <objeto> seguido de TABLEUDATE se aplica a cualquier motor.

[mapner]

Victor Hugo, lo que decís es cierto siempre que lo ejecutes en VFP, lamentablemente esto no funciona Stores Procedures o cualquier PL/SQL de motores SQL externos, mi comentario apuntando a la sintaxis del comando INSERT era un poco más extensivo que el uso de VFP. Saludos.