In 4.5.x and 4.6.x versions (and perhaps even earler) there are (in the DotNetNuke.Entities.Portals.PortalSettings class) shared/static methods to both set and update portal wide settings (stored in the ModuleSettings table keyed on the ModuleID of the SiteSettings module):
Public Shared Function GetSiteSetting (PortalId as Integer, SettingName as String) As String
Public Shared Sub UpdateSiteSetting(PortalId as Integer, SettingName As String, SettingValue As String)
While this can be helpful for truly portal wide settings, I am concerned that as developers begin using this capability we will begin to see some horrible key colisions so if you go this route, be sure to prefix the SettingName with a unique identifier such as "WESNet_" or "WESNet_Families".
Some time ago (around DNN ver 3.1) I had proposed in these forums the need for more global module settings keyed by DesktopModuleId and PortalId and have included in a custom base class (which inherits PortalModuleBase) for any modules I develop the methods for getting and updating such settings from a table WESNet_DesktopModuleSettings which I initially create (along with the related stored proceedures) as part of the install of a "dummy" module that includes some other controls, sprocs, HttpHandler, etc. common to several of my modules. By keying the setting on the DesktopModuleId as well as PortalId, the same setting name can be used without conflict in other unrelated modules.
In a complex module or several related modules with many settings, I've also used Mitch's suggestion of creating a database table keyed by PortalId and one column for each setting. This gives the advantage of strongly typed data as opposed to all values being stored as characters or text and makes sql joins on one or more settings far easier. The disadvantage is having to code the info class/controller/dataprovider/sprocs for the custom table and then remembering to modify the code each time a setting column is added.