Huge Database improvements: 

It has been a while since I profiled DNN so I am not sure when the changes were made, but the number of calls to the database have been greatly reduced.   When I profiled DNN with a sample page containing three HTML modules, the first time the page came up took 20 trips (not counting the “sp_reset_connection” which are common) and coming to the page a second time after moving to others pages, only caused 10 trips.  This is a major change from the past!  Good going DNN Team!

One thing I would really like to have is a generic form of data store.  Many modules do not require anything above simple storage.  I know there is the TabModuleSettings feature to store some data, but this is limited to 2K per setting.  It would be wonderful to have a form of data storage that is simply a hashtable persisted to a varbinary(MAX) .  Modules such as HTML/Text could use this for its data as could many other modules.  

It would be great to have a simple hashtable data storage where a developer did not have to build out DALs for data that does not require the power of a database.  Kind of like the Isolated Storage in .NET but per module instance.  Another nice feature is that you could grab the data along with the module information in one whack instead of having to make more trips to the database.  Of course, it also means you do not have to build out DALs for new database engines.  Also, the data is kept in the DNN tables making it easier to move/backup/restore the data.

In the past I modified the size of the TabModuleSettings field to allow for large data, but it would be great if this were built in and developers encouraged to use it in their modules were appropriate.

Another thing I did in the past, I built a table that more or less allowed multiple hashtables to be stored per module instance.  Such as:

HashedDataStore
(
     DataStoreKey(PK, nvarchar(128), not null)
     ModuleId(PK, int, not null
     DateLastUpdated(datetime, not null) -- (To allow for internal caching in my code)
     DataStore(image, not null) -- I used image for storing a binary copy of the hashtable
)
 
Then in my modules I could access my data stores by calling:

Hashtable ReadDataStore(Module_ID, string DataStoreKey)
WriteDataStore(Module_ID, string DataStore, Hashtable data)
DeleteDataStore(Module_ID, string DataStore)

As an example, I built a simple articles module, which would list a number of articles and display a chosen article.  The primary hashtable for the module (I like I would us in the TabModuleSettings to store with the module) would contain a list of articles consisting of the title of the article and the datastore name given to the article.  If they user selected an article it would call the article from the hashtable  storage using the ReadDataStore by the datastore name of the article.  This of course, requires a trip to the database to pick up the article, but I ended up with an articles module (which I use to this day) that did not have one line of SQL, nor was it dependant on any given database engine and at the same time did performance did not suffer.

This kind of method is not suited for all modules, if they need paging, sorting, complex data storage/queries, then a person would want to go the database route.  However, if a module only requires simple data storage this kind of system could work very well and help with database independency.

Any thoughts?

For simple modules though, hashtables can work well, much like an ini file or session state.  The routines I use have them simply because they are flexible and not structured to any given type while still easy for the routine to serialize them out into a binary data field. 

For example, in that articles module I was talking about, it only accesses the data in a couple places and requires no real effort, such as the article head which is an serializable custom class array.  Often the only place you interact with the hashtable is the point of reading/writing your custom data classes, but if a person only has to store one or two values, they might just call the hashtable for those values and cast as they use them, would be up to the developer.  It is much easier for some less experienced developers to plug a value into a hashtable than create classes that are serialazble.

The main point though, is an easy to use non-structured generic data store could be quite valuable to both make it easier to create simple modules while still remaining database independant.

Thanks for the response!