Hola, buenos días, en la uni hace unas semanas hicimos un proyecto con Spring+MySQL y tuvimos que hacer las CRUD de todas las entidades, al haber problemas con una borrada en cascada, (horas que le metí de documentación y StackOv.) me dijo que lo hiciera rápido y que funcionara que no me preocupara por como borraba y añadió "si en las empresas que trabajéis no se suelen borrar cosas" y eso me llamó mucho la atención. ¿Es cierto que en las grandes bases de datos no se suelen borrar cosas? Me imagino que en ese caso pasarán a un estado "DELETED" con algún atributo o algo pero persistidas. Contadme experiencias y no paséis a criticar a mi profesor, el tiene las suyas.
Es una pregunta muy amplia, pero por mi experiencia podría afirmar que como tu imaginas en la mayor parte de ocasiones no se borran registros de una BBDD (a no ser que sean erroneos) sino que se etiquetan como "borrados".
En los tiempos que corren ya sabrás que existen muchas formas de sacarle "jugo" a los datos desde diferentes perspectivas mediante el business intelligence, en ese sentido un registro borrado no alimenta.
Te cuento desde mi experiencia, estoy trasteando con Laravel y me encontré que implementa lo que llama soft-delete.
http://laravel.com/docs/5.0/eloquent#soft-deleting
Que es básicamente un campo más en la tabla de la base de datos (deleted_at) para marcar que ese registro está "borrado". No aparecerá en las búsquedas a menos que especifiques que quieres también esos campos y puedes recuperarlos llegado el punto.
Vamos, que al desarrollar un framework como ese tengan en cuenta poner algo así, me parece una respuesta válida para tu pregunta. :D
Me parece muy útil tu respuesta ya que no tenia conocimiento de la existencia de esta técnica. Me parece muy útil que sea una caja negra para los programadores a no ser que se especifique. Gracias por tu respuesta!
Te recomiendo en lo posible no borrar los datos, pero hay veces que es inevitable, te presento una herramienta muy útil de la gente de percona, se llama pt-archiver, lo bueno que no te satura el servidor de producción ni genera lag para lás replicas (y hace más cosas), te exporta los datos a una DDBB externa cosa que recomiendo de momento, en caso de que haya un problema mueves los datos a su punto original y problema resuelto, y sino, puedes exportarlos a un fichero CSV. Lo malo de cuando eliminas registros es que creas una fragmentación de la tabla, y puedes notar que no mejora mucho el rendimiento, por eso luego debes hacer un ANALYZE & OPTIMIZE a las tablas afectadas, cuidado con el bloqueo de tablas, puedes evitarlo usando esta otra herramienta pt-online-schema-change. Suerte!
Te voy a poner 2 ejemplos, uno en el que si se pueden borrar los datos y otro en el que no se deben borrar.
Ejemplo 1: Aplicación online sincronizada con multiples usuarios. En este caso no se borrarían los datos.
Digamos que tienes aplicación sincronizada con apps móviles que deben funcionar sin conexión y sincronizar cuando tengan conexión.
Si un usuario borra algo en el dispositivo y el borrado se sincroniza con el servidor, si lo eliminas del todo, como saben los demás usuario que se ha borrado del servidor? Podrían enviar todos los identificadores de todo lo que tienen y hacer una comparación con lo que hay en el servidor, pero si hay muchos datos puede llevar mucho tiempo y transmisión de datos. Pero si simplemente envían un timestamp desde la última sincronización que fue correcta y el servidor devuelve los ids de los elementos que han sido modificados como "borrados" después de ese timestamp, a penas transmites datos y es bastante sencillo.
Ejemplo 2: gestor de contenidos de una intranet. Todo el mundo trabaja en la misma intranet, todo se almacena directamente en la base de datos, y hay x personas generando contenido que cada mes caduca y deja de ser válido, con el paso de los meses la base de datos no para de crecer y la aplicación se vuelve mas lenta porque hay mucho contenido inútil que rara vez puede ser reutilizado. En este caso lo borras.
Este caso no es muy común, pero yo he estado en un proyecto así, eran 3-4 personas generando contenido 8-10 horas al día, muchas imágenes, muchas relaciones entre los tipos de contenido que hacían lento cuando hacías las consultas para relacionarlo
En el caso 2, lo que habitualmente se hace es una base de datos "histórica", donde volcar periódicamente los contenidos que caducan, y así no se pierden, y aligeramos la BD principal.
pues si, hubiese sido buena idea, nosotros lo borrabamos sin más, y una vez que nos pidieron estadísticas tuvimos que tirar de backups, si hubiesemos tenido la BBDD histórica nos hubiesen ahorrado trabajo de andar restaurando copias y ejecutando consultas copia por copia
Un saludo.
11/11/2015 19:36
10/11/2015 12:53
En los tiempos que corren ya sabrás que existen muchas formas de sacarle "jugo" a los datos desde diferentes perspectivas mediante el business intelligence, en ese sentido un registro borrado no alimenta.
22/11/2015 12:41
24/11/2015 13:57
http://laravel.com/docs/5.0/eloquent#soft-deleting
Que es básicamente un campo más en la tabla de la base de datos (deleted_at) para marcar que ese registro está "borrado". No aparecerá en las búsquedas a menos que especifiques que quieres también esos campos y puedes recuperarlos llegado el punto.
Vamos, que al desarrollar un framework como ese tengan en cuenta poner algo así, me parece una respuesta válida para tu pregunta. :D
28/11/2015 06:49
01/02/2016 09:18
14/12/2015 19:55
Ejemplo 1: Aplicación online sincronizada con multiples usuarios. En este caso no se borrarían los datos.
Digamos que tienes aplicación sincronizada con apps móviles que deben funcionar sin conexión y sincronizar cuando tengan conexión.
Si un usuario borra algo en el dispositivo y el borrado se sincroniza con el servidor, si lo eliminas del todo, como saben los demás usuario que se ha borrado del servidor? Podrían enviar todos los identificadores de todo lo que tienen y hacer una comparación con lo que hay en el servidor, pero si hay muchos datos puede llevar mucho tiempo y transmisión de datos. Pero si simplemente envían un timestamp desde la última sincronización que fue correcta y el servidor devuelve los ids de los elementos que han sido modificados como "borrados" después de ese timestamp, a penas transmites datos y es bastante sencillo.
Ejemplo 2: gestor de contenidos de una intranet. Todo el mundo trabaja en la misma intranet, todo se almacena directamente en la base de datos, y hay x personas generando contenido que cada mes caduca y deja de ser válido, con el paso de los meses la base de datos no para de crecer y la aplicación se vuelve mas lenta porque hay mucho contenido inútil que rara vez puede ser reutilizado. En este caso lo borras.
Este caso no es muy común, pero yo he estado en un proyecto así, eran 3-4 personas generando contenido 8-10 horas al día, muchas imágenes, muchas relaciones entre los tipos de contenido que hacían lento cuando hacías las consultas para relacionarlo
14/12/2015 21:09
En el caso 2, lo que habitualmente se hace es una base de datos "histórica", donde volcar periódicamente los contenidos que caducan, y así no se pierden, y aligeramos la BD principal.
14/12/2015 21:37