Michael

What do you suggest?  What other options are there?  The only other possible solution I see is for every third party module to include a scheduler job that runs periodically to delete related third party data whenever a user record is deleted...  That is not scalable.   I have several very large installtions that need real time updates on user data.  So, unless the sceduler job is running constantly, it won't provide real-time updates.   And if it was running constantly ... well thats just a silly amount of overhead and waste of resources to handle referential integrity that should be handled at the DB level.

If there is another viable option, I am all ears.

At the end of the day, DNN is a framework that is meant to be extended.  In order to that, there must be SOME things in the framework that are stable enough to build upon.   I don't think it is too much to say the Users table will always have UserID as a primary key, which can be referenced by third party modules.  Especially when the framework provides  no mechanism to tie into a delete event for a core object.

You can make your own module to allow administrators to add and delete users. Then you can perform any other "cleanup" you need :)

IMHO data integrity can only be guaranteed if you force it at the database level. Foreign keys in combination with cascade delete are one the best ways to do that. AFAIK almost all modules have a foreign key between the module data and the modules table (based on moduleid).

deleteing tables and recreating them is something that should not happen anyway :)

Handling foreign keys at core tables properly is more work, but not impossible. If a table change is done that needs a FK dropped temporarily and recreated after the change, that can be done... have a look at RedGate sql comparer.. they do it all the time

DNN Blog | Twitter: @erikvb | LinkedIn: