In almost all cases a module developer will install a custom module's tables, stored procedures and other database objects in the DNN database. Proper attention to object naming is important. In addition to supporting the {databaseOwner} and {objectQualifier} tokens in your module's SQL scripts, you should prefix all custom database object names with characters unique to your company and particular module. For example, I would use WESNet_EventAThon_Events for a custom table and WESNet_EventAThon_Events_GetAll for a stored procedure rather than Events and GetAllEvents respectively to avoid (as much as possible) conflicts with core and other third party objects. If you are making use of ModuleSettings and TabModuleSettings, please use similar naming conventions for settings keys.

Also, be very wary of creating foreign key relationships between columns of your custom tables and core tables. A FK constraint on the DNN Modules table ModuleID column is unfortunately a requirement that's hard to avoid but a FK constraint on the DNN Users table UserID column is considered a bad practice and is expected to cause problems with forthcoming upgrades to soft-deleted user management.

Another evil to avoid is direct manipulation of core table data in SQL stored procedures. This was especially driven home to developers who had directly accessed the ModuleTitle column of the core Modules table. That column was moved to the TabModules table in DNN 5.5.0 causing several well known modules to break - I must admit that I was one of the guilty developers in my Forge ePrayer project. Access to core data should be only made through the public API's which are much less likely to see breaking changes than the database schema.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Thanks Wes. That was an excellent explanation.