Lectura sugerid

Similar: ¿Soft elimina una buena idea?Buen artículo:http: //weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.asp

Cómo terminé aquí

Creo firmemente que cuando se hace software, cualquier cosa que se haga por adelantado para minimizar el trabajo más adelante vale la pena en las cargas de camiones. Como tal, estoy tratando de asegurarme, al acercarme al esquema y mantenimiento de mi base de datos, de que pueda mantener la integridad relacional sin ser arcaico o demasiado complejo.

Esto resultó en una especie de estremecimiento al mirar el enfoque de eliminación típico, CASCADE. Vaya, un poco exagerado para mi situación actual. Quería mantener la integridad del gráfico relacional, pero no quería eliminar cada gráfico solo porque una parte de la cadena era irrelevante. Por lo tanto, opté por el camino de la eliminación suave para asegurarme de que la integridad de los datos permanecería mientras los registros pudieran eliminarse de la relevancia. Lo logré agregando un campo "DateDeleted" acad, suspiro, tabla en la base de datos.

Punto de retorn

Sin embargo, esto claramente está comenzando a agregar demasiada complejidad y trabajo para que valga la pena. Incluyo lógica donde no debería ir y no tengo ganas de perpetuar estas malas prácticas en toda mi aplicación. En resumen, voy a revertir esta implementación.

Al buscar el clima o no a las personas les gusta eliminar suavemente, parece que haymuch de apoyo para ello. De hecho, la publicación "similar" enlazada muestra una respuesta de "siempre borro suavemente". Además, la mayoría de las respuestas allí y alrededor de SO incluyen algún tipo de enfoque "isDeleted" o "isActive".

Nueva idea de implementación

El enlace "Buen artículo" cubre algunos de los problemas que realmente comencé a encontrar. También sugiere una alternativa a la eliminación suave que encontré desde el punto de vista de las mejores prácticas. La sugerencia es utilizar una "Base de datos de archivado", que en realidad había considerado al mirar la eliminación suave. La razón por la que decidí no hacerlo fue por la observación que hice anteriormente sobre la eliminación de CASCADE. Tengo cuidado de eliminar gráficos completos de la base de datos porque se elimina una parte de la cadena. Sin embargo, este gráfico podría conservarse al menos del archivo, por lo que no estoy seguro de que sea realmente tan terrible.

Cruc

Entonces, ¿debería seguir agregando lógica, lógica, lógica ... lógica? O, ¿debería considerar hacer la base de datos de archivo donde la mayoría de la lógica simplemente se ubicaría en una clase de administración de gráficos muy compleja para almacenar / restaurar gráficos de objetos relacionales? Esto último parece ser la mejor práctica para mí.