Лучше посмотреть, как выглядят имена таблиц:
- 2009_articles
- 2010_articles
- 2011_articles
- 2009_customers
- 2010_customers
- 2011_customers
- 2009_invoices
- 2010_invoices
- 2011_invoices
Разработчики смоделировали какое-то разделение (задолго до того, как MySQL его поддерживал), но теперь это мешает любой попытке создать быстрый интерфейс, чтобы клиенты могли видеть свои счета и менять годы.
Через пару месяцев у меня получились следующие результаты:
Изменение Invoice._meta.db_table бесполезно, потому что любое другое отношение, выведенное ORM, будет неправильным
models.py не может получить переменные запроса
Вариант а:
Используйте абстрактные модели, чтобы Invoice10 добавил meta.db_table = 2010 и наследовал от модели Invoice, а Invoice11 добавил meta.db_table = 2011, не DRY, хотя приложение не должно поддерживать более двух или трех лет одновременно, но я все равно придется проверить, если
Вариант b:
Дублируем модели и меняем импорт по моим представлениям:
если год == 2010:
из моделей импорт Артикул 10 как Артикул
и т. Д.
Опция c:
Динамические модели, упоминаемые в нескольких местах в сети, но зачем использовать 100% динамическую модель, когда мне просто нужна 1% часть динамической модели?
Опция d:
Вау, просто схожу с ума после разочарования. А как насчет нескольких настроек базы данных и использования маршрутизатора?
Любая помощь будет высоко ценится.