Обычно хранимые процедуры следуют шаблону CRUD (http://en.wikipedia.org/wiki/Create,_read,_update_and_delete)), но они не должны ограничиваться этим.
1) Возможно, вы хотите объединить обновление и вставку. Если первичный ключ заполнен, то это обновление, в противном случае это вставка. Для GUID и других сгенерированных клиентом ключей вы сначала обновляетесь, и если число строк равно нулю, вам необходимо выполнить вставку. Процедура вставки / обновления обычно возвращает первичный ключ.
Вам понадобится процедура get_by_id, а также некоторое количество критериев get_by_non-unique-критерия, которые возвращают любое количество строк. Идея состоит в том, чтобы убедиться, что столбцы в наборе результатов идентичны во всех процедурах get / list.
Цель этих процедур - не обязательно одна таблица или даже одно представление, а скорее логическая сущность, поэтому вам может потребоваться выполнить различные объединения как для связей, так и для поиска. Это может помочь вернуть несколько наборов результатов.
2) Представления удобны, но не имеют к этому никакого отношения. Иногда они помогают с повторным использованием, но не всегда.
3) Все зависит от бизнес-правил. Конечно, вы можете предотвратить некоторые виды повреждения данных на уровне хранимых процедур, но существуют ограничения на то, сколько они могут или должны знать. Тем не менее, существуют специальные случаи, когда вы можете захотеть добавить больше логики в процесс, например, login.
4) Вы не всегда можете сделать это, но иногда вы можете выделить общий код в низкоуровневые стандартные процессы, которые пользователь не вызывает.
Надеюсь, это начало.