Thank you for the explanations and links. It appears that my thinking was rather backward, for I thought a larger number of tables containing fewer records would be more efficient in some manner. The concept of a relation schema as opposed to a table being a generic empty container to hold records is very helpful. In that respect, I don't need four tables to hold the data across all portfolios. Since nearly all the data is being generated by the user from within the web extension, all the tables are comprised only of some type of compound key(perhaps multiple columns, indicating portfolio, module, tab, page, component) and a JSON string. The only exception is the media data types as blobs. If it's better to keep the blobs separate, then two tables would be sufficient; otherwise, one table would be. Although the JSON strings contain different collections of information, there is only one distinct fact type and no relationships as long as the strings are never parsed in C. I will never need to perform a join in this particular application; only inserts, replaces, and selections based on the compound keys. If the JSON strings were parsed into separate columns, then there would be different facts and relationships, but, in this simple case, it just makes more work for the application to stringify in Javascript to parse in C in order to write to SQLite database (and almost never use the data in C) and then retrieve and stringify it in C to send back to JavaScript to parse again. I have an upcoming project in which the scenario is more complex (for my skill level anyway) and the information you provided corrects my view of a number of items that will be helpful to me. Thanks again.