Split database.json

[kevinsumner]

What do you think about splitting database.json into one JSON file per motor? Maybe a folder structure with manufacturer as the containing folder? E.g.:

motors
├── FPV_Cycle
│   └── 25MM-1870KV.json
├── T-Motor
│   ├── F1404-2900KV.json
│   ├── F1404-3800KV.json
│   ├── F1404-4600KV.json
│   ├── M0802-22000KV.json
│   ├── M0802-25000KV.json
│   └── M0802-27000KV.json
└── iFlight
    ├── Xing2_1404-3000KV.json
    ├── Xing2_1404-3800KV.json
    ├── Xing2_1404-4600KV.json
    ├── Xing2_2207-1855KV.json
    └── Xing2_2207-2755KV.json

On the upside, this would ease finding and updating existing entries. However, it'll require something like "compiling" database.json in a GitHub action on main branch updates or updating the database loader code.

I don't mind doing the work, but I want to know if this is a reasonable direction before I do the work.

[kevinsumner]

Compiling database.json would allow a pass to do some calculated values, like Stator Volume and Stator Ratio, so motors of different sizes can be more easily compared.

[marc-frank]

That's an interesting idea, thanks.
Is that how it's usually done?

I liked the idea of a single file. It's very easy to load it into Excel and convert back to json. Multiple files would make that more complex.

And creating a whole new database (batteries, esc's, ...) would be as easy as changing the database file and adjusting the default header ordering.

Calculating Stator Volume and aspect ratio is something I thought about as well. I think that can be done before sending the contents to DataTables without adding another field in the json file.

[kevinsumner]

This is a common approach to data sets like this. Obviously, it doesn't maintain your Excel workflow, though.

Typically, there will be a template file and a strict schema (e.g., defined as JSON Schema), with schema compliance checked at pull request time. Adding a new entry is just copying the template to a new file and editing with a text editor. This is obviously optional process that gets more valuable as more contributors are submitting updates.

In moving away from an Excel-based workflow, where the data is only 2-dimensional, some fields can become more complex data types. Particularly, KV typically doesn't have a significant impact on other motor specs (e.g. weight), so having individual motor entries for each KV increases maintenance costs that can be mitigated by having a multi-value field for KV instead.

I maintain a database of sorts with a lot of different products, including motors, for myself. I haven't shared it, but have considered doing something like this. My plan is to integrate my list of motors into this and delete my personal copy. If scope here goes beyond motors, I'd be very happy to contribute the rest as well.