papelera de reciclaje

[lilith_sr]

hola chicos (as)!!

solo tengo una pregunta bueno dos!!!, alguien ha hecho una papelera(tabla de reciclaje) donde se almacenen los registros que eliminas de una BD para que en un momento dado pueda recuperlarlos?, que sugerencias me dan para hacerla ya que la que hice no funciona del todo!!!...me funciona cuando no se repiten registro, pero cuando se repiten ya no hace lo que debe hacer!!!....alguien me puede dar una idea!!
Gracias

[thisisalexis]

Corrígeme si me equivoco, pero al menos que trabajes con el paquete de soluciones orientadas a Bussines Inteligence de Oracle, me parece que no vas a poder hacerlo, al menos no de forma o´ptima.

Tu estás diciendo que ya hiciste una, explícame cómo entonces, porque no tengo idea cómo lograrlo.

Lo que yo haría sería, en lugar de eliminar los valores, asignarles varios status, uno de ellos seria "archivado"

Saludos

[lilith_sr]

creo que no me explique muy bien..jejejee

mira tengo x tablas en mi BD, entonces cuando por ejemplo elimino un registro de la tabla 1 este se almacena en otra tabla que tiene la misma estructura que la tabla1, en realidad no se elimina de la DB si no de la tabla.....

[david_M_G]

Iniciado por lilith_sr

creo que no me explique muy bien..jejejee

mira tengo x tablas en mi BD, entonces cuando por ejemplo elimino un registro de la tabla 1 este se almacena en otra tabla que tiene la misma estructura que la tabla1, en realidad no se elimina de la DB si no de la tabla.....

Por eso es mejor asignar un estatus, como dice thisisalexis.

En vez de cambiarlo de tabla, cambias el valor archivado a "encendido" o "apagado". Si está encendido lo coges, si está apagado no. Y siempre los puedes recuperar. El conjunto de apagados forman la supuesta papelera. ¿Me he explicado?

saludos

[g05l21]

Yo creo que es mejor hacerlo como bien dice lilith_sr, a no ser que tengas limitado el número de tablas.

Un simple insert (+ delete) no se lleva mucho con el update, que serían las dos consultas básicas que tendría que hacer, y a cambio ganas en claridad con las bases de datos, facilidad de acceso y rendimiento.

Tan solo pensar en una aplicación que borre y cree 50 registros al día. Al final de un mes la tabla tendría unos 1500 registros de los cuales solo 50 son necesarios, perjudicando el resto de accesos a la base de datos.

A parte de esto, tendrás el problema de "limpiar la papelera" ya que nunca sabrías que archivos tienen más del tiempo mínimo necesario. (para ello, yo añadiría una variable date en la tabla nueva).

Aun así, lilith_sr, puede que te falle porque algo en el código no está del todo correcto. Pon el código a ver si vemos que le pasa.

Saludos!

[thisisalexis]

Sigo pensando que es mejore el método que yo propongo, crear un campo status. Mientras hagas bien las consultas SQL no se verá afectado en lo absoluto el rendimiento de la base de datos, es decir, la tabla puede tener 50000 registros archivados y sólo 10 que se pueden mostrar, y si colocas un simple "WHERE tabla.status = 2" (Los no archivado) te devolvería esos 10, no estas sobrecargado a tu servidor ni nada por el estilo. Ahora, haciendo lo que estás haciendo, eliminando de una tabla y pasando para otra, si estarías poniendo a trabajar más de la cuenta tanto a tu base de datos como a tu servidor apache.

Saludos

[g05l21]

Jeje.

Para gustos colores

Yo trabajo más como con dos bases de datos que guarreando una sola, ya que para mi es mejor tener un uso mínimo en una bd de 5000 registros y uno masivo en una de 10 que tener un uso masivo en una de 5000.

Pero vamos, eso ya se mete en el tema de optimización de bd y eso es muuuy largo y complejo :-p


Definitivamente, dependerá de lo que quiera "lilith_sr" que es la que lo va a usar

[lilith_sr]

hola!!....antes que nada gracias por las sugerencias....decidi borrar e insertar, para no llenar de registros las tablas y no alentar las busquedas.....y no se me habia ocurrido lo de la fecha, pero se lo añadire, gracias a los dos....besos

[nicolaspar]

Cuando menos deletes hagas mucho mejor. El usar bajas lógicas (el mencionado campo status al que apruebo) y no físicas es lo mejor en cuanto a optimización.

Estado 1 = Backend / Front
Estado 0 = Backend
Estado -1 = Recycler
Estado -2 = Delete forever.

(Cuantas cosas bonitas se pueden hacer con estos estados :) )

[emiliodeg]

Iniciado por nicolaspar

Cuando menos deletes hagas mucho mejor. El usar bajas lógicas (el mencionado campo status al que apruebo) y no físicas es lo mejor en cuanto a optimización.

Estado 1 = Backend / Front
Estado 0 = Backend
Estado -1 = Recycler
Estado -2 = Delete forever.

(Cuantas cosas bonitas se pueden hacer con estos estados :) )

para mi esta es la mejor solucion

[bAxTErCL]

Genial, no se me habia ocurrido esta idea :)

y para mi también es óptimo usar "estados" numericos y no alfanumericos.