Supervisor suggests marking records with an isDeleted flag rather than permanently removing them. However, how should one handle unique field conflicts and manage eventual deletion of outdated records to manage storage?
I have implemented similar strategies in past projects where marking records with an isDeleted flag proved practical. To handle unique field conflicts, I suggest either appending a unique identifier to the field once a record is marked as deleted or adjusting your business logic so that the uniqueness constraint only applies to active records. For eventual permanent deletion, a scheduled background process that archives old records before removing them can help manage storage without immediate system downtime. This approach maintains database integrity and provides a fallback if records need to be retrieved later.
hey, im wonderin if offloading deletd records to an archive table could help. that way, active records are clean and conflict free, and you could manage storag better. what do u think about using this method?
Based on previous experiences, combining an isDeleted flag with an additional timestamp such as deletedAt has proven beneficial. This method allows the system to differentiate between active and inactive records, thereby isolating unique field validations to the active dataset. Adjusting the constraints through application logic rather than directly on the database helps prevent conflicts. Furthermore, implementing a maintenance routine to move or purge records that have been soft deleted for a certain period aids in managing storage without sacrificing historical data when necessary.
hey, i was tinkering with a setup where archived records go to a separate table, easing unique keys on active ones. any experince with a split approach? might be cool to blend both methods
i’ve found a mix approach works. use the flag and adjust unique checks to exclude deleted ones, then run periodic cleanups. keeps storag light and avoids conflicts—all in all, it’s worked well in my experience