1

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:

table api_data

id
tags
general_path
path_content
product_id
search (keywords to index)
overhead_id
version_id

table api_data_overhead

id
product_id
file_overhead

table api_product_versions

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.

2

Keywords for indexing -- Either put it in a TEXT and apply a FULLTEXT index, or put the keywords one-per-row in another table (which is indexed).

To critique a schema, we need to see the main SELECTs that you will have.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.