That's funny, I'm just working on a similar application. My approach is to leave the Store as it is (especially when something is in beta) and use utility functions to get/set the information as required.

For example, I have an Excel spreadsheet with a list of Products that already includes a Category column with 1000's of rows. Using a standard OledbDataReader I can get a list of unique Categories like this...

Public Function ExportCategories() as OleDbDataReader
Return New OleDbCommand("select distinct category from [items$] group by category", Connection).ExecuteReader

Then I with a collection of Store CategoryIDs...

Public Function GetStoreCategories() As Collection
Dim s As String = String.Format("select categoryid,categoryname from Store_Categories where PortalID={0}", PortalID)
Dim cc As New Collection
Dim cdr As SqlDataReader = New SqlCommand(s, Connection).ExecuteReader
While cdr.Read
   cc.Add(cdr(0), cdr(1))
End While
Return cc

...Now I can add MyProducts to the StoreProducts Table. To verify a category I use Collection.Contains("Cat1") or to get the StoreCategoryID I use Collection("Cat1") 

I have written many system using this approach. I rarely use 1 to 1 relationships because something will always get out of sync or worse. I treat the Store tables as "foreign keys", but I would never allow my application or DotNetNuke to enforce the constraints. Sure you can add your own stored procs but you also have to provide a mechanism to remove them as well.

As far as best practices, I prefer real world use. If an application already works, any added functionality should not break it.

I would be happy to discuss any other ideas or suggestions about this thread. It is a very interesting (and common) programming issue.