DB model question

gistfile1.txt

In my dive logging app, I am considering allowing the user to create their own logger. Let me explain. 

Rather than having to fill out a hundred fields every time the user dives, I'm considering setting it up so that the user can choose what categories and fields they want to use every time they log, i.e. they can build a "logger". For example: what if they only want to log the weather and their max depth? Great, they can build a logger that only has those two fields to fill out.

I was also considering offering the user the ability to create their own categories and fields to be logged. Which is where it gets more complicated.

I was thinking of setting up the database like so. The following are all the tables for the logger builder:
- `loggers`
all the loggers the user has made
- `logger_category_types`
all the logger categories available to the user (created or hardcoded). i.e. weather.
- `logger_input_types`
all the input field types (under a category) that the user could choose to have in a logger. i.e. strength of current.
- `logger_category_entries`
all the categories that have been entered into a particular logger. Each of these would relate to the logger they are used in, and a "logger_category_type"
- `logger_input_entries`
all the input fields that the user has entered into a particular logger. Each of these would be related to the logger they are used in, and a particular "logger_input_type"

Now for the actual log-related tables themselves:
- `all_logs`
- `log_category_entries`
- `log_input_entries`
Obviously all of these would be related their respective _types from the logger builder tables above.

Now, I'm not sure if this is too robust a system, but it feels like it. It feels like a lot of tables.
I'd really love some feedback on this process and whether or not I'm overengineering this system or not.

EDIT:
I've actually started considering that I don't really want the user to be able to customize everything. 
Or, at the very least, I'd like to limit their customization in order to be able to use statistical data
later on based on users that have filled-out similar fields.