I am displaying documentation using Swagger, but the documentations are long so I made a side menu and split up the data in the database. Splitting it up, it allows me to search for specific areas and endpoints of the documentation and display it, and only display what is selected instead of everything, every time.
There are different versions of the documentation so some of the information overlaps. I am not sure the best way to store this, and currently, it is separated by version of the same documentation but there is a lot of redundancy since a lot of data overlaps from the previous versions.
Currently, the structure is similar to this:
id tags general_path path_content product_id search (keywords to index) overhead_id version_id
id product_id file_overhead
id active product_id name
The overhead for the file contains a lot of common information for every path for that documentation file. It is very long but doesnt need to be indexed or searched.
I am looking for a way to improve this database design as it grows and more documentations are added. I am concerned with performance when searching and uploading data. There is a lot of redundancy right now, and wondering if it can be better.