Ни то, ни другое. Лучшим инструментом для этой работы является проверка модели - вы можете написать здесь свое собственное правило проверки, и оно будет применяться администратором и вашими собственными приложениями.
Вы можете использовать триггеры для обеспечения соблюдения такого рода ограничений, но я бы не стал на это полагаться. Это может быть выполнено только в качестве вторичного применения, в то время как первичным должно быть проверка модели, как уже сказал Даниэль.
Что касается триггеров DB и сигналов Django , они больше отличаются от обычных. Единственное, что у них общего, это то, что оба они вызываются при изменении сущности. Но сущности очень сильно различаются.
Триггеры отслеживают изменения строк базы данных, таким образом, они работают с необработанными табличными данными. Код триггера запускается СУБД.
В отличие от триггеров сигналов отслеживают изменения объекта домена. В общем случае модель Django состоит из данных из нескольких строк таблицы (учитывайте наследование модели и связанные подмножества объектов). Сигнальный код выполняется Django.