Выполнение триггера всегда сопряжено с некоторыми накладными расходами - как минимум, вы выполняете переключение контекста с механизма SQL на механизм PL / SQL для каждой строки, которая вызывает срабатывание триггера. Хотя абсолютная величина накладных расходов на запуск триггера относительно постоянна, процентные накладные расходы сильно варьируются в зависимости от того, как вы выполняете DML. Если у вас есть приложение, которое добавляет или изменяет строки в наборах, что является самым быстрым способом работы с реляционными данными, триггеры оказывают гораздо большее относительное влияние на производительность, потому что стоимость этих контекстных сдвигов плюс стоимость любого фактического триггера делает, быстро доминирует стоимость выполнения запуска DML.
Теоретически, триггер может использоваться для обеспечения сложных ограничений, поскольку триггер может запрашивать другие таблицы или вызывать функции для выполнения сложных сравнений. На практике, однако, чрезвычайно трудно, если не невозможно, кодировать эти триггеры способом, который на самом деле является правильным в многопользовательской среде, поэтому, как правило, не очень хорошая идея проектировать систему, которая потребовала бы ограничений, которые смотрят на данные через столы. Как правило, это указывает на проблему с моделью данных.