As the data will be segregated on a per module basis, you will definitely need ModuleId (usually with a foreign key relationship to the core Modules table with cascade delete enabled) as well as an ItemID  (primary key - identity) or similarly meaningful column name to distinguish between multiple items of data associated witht he same module.

Since ModuleID is unique to a each portal, you do not need to include a PortalID column even if the module will be used (with different data) on multiple portals. The only time that I include PortalID (and not a ModuleID) is when writing a module whose data will be available to any instance of the module across an entire portal but not across all portals of the same installation.

You do not need to include a TabID column. If only the views and other presentation settings (and not the data) of the module will be different between copies of the same module (placed with the Add EXISTING Module rather than Add NEW Module command, you can take advantage that copy modules will all have the same ModuleID but different TabModuleID's. The DNN framework provides a means of storing a module's custom settings in either the ModuleSettings table (by ModuleID and settings key) or the TabModuleSettings table (by TabModuleID and settings key). Include on the module's custom settings control a way of specifying the desired view of the data and store that value to TabModuleSettings. Then, in the module controls Init or Load handler you can first obtain which view is to be displayed then render the view accordingly. That way, you can have multiple copies of the same module each with a different view to the data.

---

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