Так мы потихоньку дойдем и до вопроса "что такое таблицы" :)...
А по сути... Триггер и хранимая процедура - суть одно и то же. Только вызов хранимой процедуры инициирует клиент (или другая хранимая процедура), а запуск триггера инициирует ОПЕРАЦИЯ (вставки / удаления / обновления). Одним словом, триггер - это процедура обработки события.
Если то, событие, которое обрабатиывает риггер, происходит слишком чсато, то нельзя триггер делать тежеловесным - будет медленно ворочаться. Особенно, если триггер сделан с использованием временных таблиц (или табличных переменных), то при каждом его вызове будет происходить его перекомпиляция, что может вызывать очень существенные задержки (у меня встречались триггеры на 1000 строк).
Вне зависимости от того, используете вы триггеры или хранимые процедуры, если в коде много ветвлений, и есть громоздкие куски кода, которые выполняются довольно редко при стечении каких-то особых обстоятельств, необходимо по возможности выделять подобные куски кода в отдельные ХП и вызывать их из основной ХП только в том случае, если в них возникла необходимость. Особенно это касается кусков кода с использованием временных таблиц и табличных переменных (которые могут приводить к перекомпиляции во время вызова). Выполнить это требование непросто, если речь идет о триггере. Дело в том, что таблицы Inserted и Deleted за пределами триггера недоступны, а в триггере обычно работа производится именно с этими двумя таблицами. С другой стороны, вызвать хранимую процедуру, которая должна обработать не одиночные параметры, а некоторую совокупность записей (возможно, весьма объемную) так просто не удастся. В этом они проигрывают триггерам.

В общем и целом, как я понимаю, существуют две концепции. Первая подразуемвает в основном использование VIEW и триггеров. Она более универсальная, поскольку с VIEW можно работать с разных клиентов без мудреного клиентского интерфейса (на простых гридах, в которых непосредственно все и правится - можно делать творить хоть в EM, хоть в Excell). Вторая концепция подразумевает для каждой таблицы заводить ХП на добавление записи (одной!), на удаление записи (опять же одной!) и на модификацию записи (опять одной!). Еще может понадобиться ХП (или VIEW) просто на селект (не следует забывать, что ХП возвращает необновляемый Recordset). Она имеет свои преимущества и свои недостатки. Пара недостатков уже прозвучала - оперирование всегда одной записью и жесткая завязка на интерфейс вызова этих ХП. Сам администратор, пожелав выполнить какую-то операцию скопом непосредственно на таблицах в обход ХП, может здорово напортачить и даже не сразу об этом узнать (это к вопросу о бизнес-логике). Однако, у этой концепции есть и свои плюсы. Есть ряд операций, которые можно выполнять в ХП, но которые нельзя выполнять в UDF, во VIEW и в триггерах. Выигрыш первой концепции по сравнению со второй также меркнет при столкновении снекоторыми глюками ADO с вычисляемыми полями VIEW (их запрещено редактировать, хотя ко VIEW прицеплен instead-триггер, который, в принципе, смог бы сделать что-то полезное с отредактированным значением, оставив при этом поле вычисляемым - тут ИМХО MS недодумала). Внимательно изучив эти ограничения и определившись с тем, собираетесь ли вы использовать те операции, которые делают вторую концепцию более выигрышной, и нужно выбрать конкретный вариант.