Одним из способов является сохранение пользовательских данных в виде полуструктурированных данных. Если вы используете PostgresQL, то JSONField. Если нет, CharField, содержащий результат (Python) json.dumps. Это превращает проблему в один из способов, позволяющих пользователю указать, какой набор данных хранить. Он имеет тенденцию становиться сложным с точки зрения динамической генерации соответствующих форм для ввода пользователем выбранных данных, и, кроме случаев использования Postgres, трудно использовать набор запросов для правильной фильтрации данных.
более распространенным подходом является определение нескольких таблиц базы данных: одна для данных о погоде, другая для (скажем) астрономических изображений, ... все они связаны с пользователем, так что простой фильтр набора запросов будет получать только наблюдения текущего пользователя (если это то, что желательно).
Легко добавить дополнительные поля данных в таблицу позднее. Вы просто редактируете модель, добавляя поле со значением по умолчанию (для добавления ко всем существующим записям - обычно нулевая или пустая строка), а затем запускаете makemigrations и migrate.
Третий Возможность - это подход SQL. Таблица, содержащая, скажем, дату / время, пользователя, идентификатор группы наборов данных, тип данных и значение данных, по одной строке на элемент данных. Это относительно просто и легко фильтровать. Он генерирует большую таблицу быстрее и является пустой тратой реляционной базы данных. Однако, если сообщество пользователей невелико, а количество строк меньше миллиона, это вряд ли будет проблемой на практике. Вы можете переместить дату и время в таблицу группы наборов данных, поэтому каждый набор данных имеет набор связанных измерений, каждое из которых содержит только тип и значение.