Django ORM и несколько динамических баз данных
Отказ от ответственности: я все еще довольно новичок в Django и не ветеран.
Я нахожусь в процессе создания "следующего поколения" программного пакета, который я создал 10 лет назад. Оригинальное программное обеспечение было построено с использованием CodeIgniter и стека LAMP. Текущее программное обеспечение все еще отлично работает, но пришло время двигаться дальше. Техника уже устарела. Я рассматривал Django для написания нового программного обеспечения, но у меня есть опасения, что использование ORM и файла моделей выйдет из-под контроля.
Вот моя ситуация, каждый клиент должен иметь свою собственную базу данных. Никаких исключений из-за конфиденциальности данных и контрактов. Каждая база данных в основном хранит данные прогноза погоды. Существует скелетная база данных, которая в настоящее время используется для настройки клиента. В этой базе есть таблицы, которые являются общими для всех клиентов. Меня беспокоят таблицы прогнозных данных, которые я должен динамически создавать. Каждая таблица прогнозов уникальна и отличается друг от друга, за исключением первых четырех столбцов таблицы, которые используются для ссылок/индексации и позволяют узнать, когда были добавлены данные. Остальные столбцы - это прогнозные значения в формате данных real/float. В таблице может быть от 12 столбцов прогнозных данных до более 365. Между всеми клиентами существуют сотни различных/уникальных таблиц прогнозов.
Я пытаюсь понять, как я могу использовать ORM, не имея сотен методов в model.py. Даже если бы я создал подкаталог, а затем "model.py" для каждого клиента, у меня все равно были бы тонны методов модели, с которыми нужно иметь дело.
Я читал о том, как работает ORM для Django, но не нашел ничего (пока), что помогло бы в моей ситуации. Это не норма.
Не затягивая, следует ли мне пропустить ORM из-за всех этих сложностей или есть какой-то стабильный способ справиться с этим, помимо SQL-запросов и хранимых процедур, чтобы получить некоторый прирост производительности?
Отметим следующее: я провел тщательное сравнение между MySQL и Postgres и буду использовать Postgres для нового проекта. Я протестировал возможность использования столбца массива против столбца для каждого прогнозного значения в Postgres, надеясь, что это поможет решить проблему потенциального разрастания модели. К моему удивлению, наличие столбца для каждого прогнозного значения обеспечило более быстрый запрос, чем хранение всего в столбце массива. Таким образом, хранение в массиве не является жизнеспособным вариантом для моих данных.