Other Software > Developer's Corner

Programming 101 Lesson: Don't Purge User Data

<< < (3/5) > >>

app103:
Purging old data...and banks...

You can almost count on it that if he had defaulted on his account and it wasn't in good standing, that his info wouldn't have been lost. They would never have purged the data related to THAT kind of closed/inactive account. They would keep that forever.

Tekzel:
I am from the BOFH school of thought:  Users are useless, and by association, so is their data.  Delete it randomly and without warning just to see them cry.

Ralf Maximus:
Recently encountered a scenario similar to this (massive database of live data, >90% "too old" to matter).  The solution we came up with:

1. Keep data that's routinely accessed in the "live" database.

2. Regularly archive older data to big, slow servers but still retain access from the main app.  If a user requests data not in the live system, a secondary query is performed in the archives.  If data is found there, it's reactivated -- moved back to live storage.

This was just implemented so I don't know how it will fare over the long haul, but so far so good.  There's a noticeable lag when the archives are hit but in this case the results are worth it, since performance when accessing live data has improved dramatically.  And users have access to everything, all the time.

OGroeger:
Whow, that sounds interesting. How do you determine that data are "old" and should be moved to the archive?

Ralf Maximus:
Every record has a "Date Created" and "Date Updated" field, standard MS date types.  It makes aging of records simple.  For a 90 day cut-off (Access database syntax):

SELECT * FROM Table WHERE DateUpdated < (Now - 90)

...or, SQL Server Syntax:

SELECT * FROM Table WHERE DateUpdated < (GetDate() - 90)

:-)

Navigation

[0] Message Index

[#] Next page

[*] Previous page