Неожиданное поведение при миграции Django при попытке использовать схемы SQL Server
В настоящее время я поддерживаю проект Django, который использует базу данных Postgres и следует принципам, изложенным в этой статье, чтобы использовать несколько схем. Это позволяет сохранить все таблицы красивыми и разделенными по именам.
У меня есть приложение 'core', где я определил базовую модель, которая имеет пару внешних ключей к моей пользовательской модели 'Auth'. Эти поля - '_created_by' и '_last_updated_by'. Каждая модель в каждом другом приложении наследуется от этой модели, и в результате каждая таблица в каждой схеме имеет связь по внешнему ключу с моей пользовательской моделью 'Auth'.
При использовании Postgres я могу перенести свое пользовательское приложение 'Auth', и оно создает все необходимые таблицы в стандартной схеме 'public'. И тогда я могу сделать:
python manage.py migrate app --database=app_db
для других моих приложений, и соответствующие таблицы создаются в правильной схеме. (Я создал схемы заранее, django не делает этого за вас)
Это прекрасно. Однако недавно стало очевидно, что моя жизнь была бы проще, если бы мы использовали SQL Server для бэкенда.
После некоторой работы все почти работает, однако когда я мигрирую приложение с помощью вышеуказанной команды, создаются дубликаты таблиц 'Auth' в схеме приложения, а также дубликаты таблиц django (content_type, migrations, group... и т.д.). Так что теперь у меня есть
dbo.custom_auth_model
dbo.django_migrations
а также
app.custom_auth_model
app.django_migrations
Как я могу предотвратить создание этих таблиц? Возможно ли это с помощью SQL Server или мне придется использовать Postgres?
Просто проиллюстрируем проблему:
Это публичная схема на моей БД Postgres
Это одна из схем одного из приложений (приложение для лицензирования собак)
и вот какой беспорядок я устроил в своей БД SQL Server
обратите внимание на все дублирующиеся таблицы на SQL Server.