Это правда, что на уровне базы данных это не вызовет никаких проблем.
Однако у вас возникнут проблемы с маршрутами URL и именами внутренних представлений!
Предположим, у вас есть два приложения - "блог" и "комментарии", и у каждого есть модель с именем Message, и каждая модель сообщения имеет соответствующий ModelViewSet (BlogMessageViewSet и CommentMessageViewSet, соответственно)
Маршрутизатор Django автоматически назовет имена ваших представлений message-list
, message-detail
и т. Д., Независимо от того, какое приложение используется в этой модели. Таким образом, у вас будут коллизии после загрузки их в маршрутизатор, так как у вас есть две модели под названием «Сообщение». Например, если в urls.py мой роутер выглядел так:
router = routers.DefaultRouter()
router.register(r'blog/message', BlogMessageViewSet)
router.register(r'comment/message', CommentMessageViewSet)
Тогда внутренне оба маршрута для / blog / message и / comment / message будут указывать на / comment / message, поскольку он был зарегистрирован последним на маршрутизаторе, а внутренне имена представлений будут message-list
, message-detail
и т. Д. ..
Вы можете решить эту проблему, назначив другое базовое имя одному из ваших представлений, хотя бы так:
router = routers.DefaultRouter()
router.register(r'blog/message', BlogMessageViewSet, view_name='blogmessage')
router.register(r'comment/message', CommentMessageViewSet)
Хотя это потребует от вас явного определения URL как HyperlinkedIdentityField на сериализаторе для BlogMessageViewSet, если вы используете HyperlinkedModelSerializer, и чтобы все ссылки на это представление в urlresolvers.reverse () или других инструментах на основе URL использовали представление название 'blockmessage.'