Вы не указали версию, но, по-видимому, речь идет о 6.х, потому что в более поздних версиях SQL Server при ALTER TABLE / VIEW выполняет автоматическую перекомпиляцию всех планов, зависящих от данной схемы. В 6.х перекомпиляция в этом случае не поможет. Простейший пример: create proc sp1 as select * from tbl, в tbl добавляем новое поле, но это никак не отражается на выдачах sp1. Единственный выход - drop / create процедуры, потому что команды ALTER PROCEDURE в 6.х тоже не было.

Да, с view какая-то задница. Радует хотя бы то, что хранимые процедуры ведут себя прилично. Ну, делать нечего, поведение view придется доработать напильником. Во-первых, drop / create заново делать не надо. alter view тоже помогает ему одуматься. И чтобы по максимуму автоматизировать этот процесс, предлагается следующая процедура:

create proc AlterView @ViewName sysname as
declare @query varchar(8000)
select @query = view_definition from information_schema.views where table_name = @ViewName
set @query = replace(@query, 'create', 'alter')
exec (@query)

После чего все работает гладко:
...
select * from v

alter table tab add d char(10)
exec AlterView 'v'
select * from v

alter table tab drop column c
exec AlterView 'v'
select * from v

Модификация предыдущей процедуры на случай, когда определение view не умещается в типе char/varchar:

CREATE PROCEDURE AlterView1 @ViewName sysname AS
declare @s varchar(100), @i int, @view_id int
select @view_id = id from sysobjects where name = @ViewName and xtype = 'V'
declare @s0 varchar(8000), @s1 varchar(8000), @s2 varchar(8000), @s3 varchar(8000), @s4 varchar(8000)
declare @s5 varchar(8000), @s6 varchar(8000), @s7 varchar(8000), @s8 varchar(8000), @s9 varchar(8000)
select @s0 = '', @s1 = '', @s2 = '', @s3 = '', @s4 = '', @s5 = '', @s6 = '', @s7 = '', @s8 = '', @s9 = ''
select @s0 = text from syscomments where id = @view_id and colid = 1
select @s1 = text from syscomments where id = @view_id and colid = 2
select @s2 = text from syscomments where id = @view_id and colid = 3
select @s3 = text from syscomments where id = @view_id and colid = 4
select @s4 = text from syscomments where id = @view_id and colid = 5
select @s5 = text from syscomments where id = @view_id and colid = 6
select @s6 = text from syscomments where id = @view_id and colid = 7
select @s7 = text from syscomments where id = @view_id and colid = 8
select @s8 = text from syscomments where id = @view_id and colid = 9
select @s9 = text from syscomments where id = @view_id and colid = 10
set @s0 = replace(@s0, 'create', 'alter')
exec (@s0 + @s1 + @s2 + @s3 + @s4 + @s5 + @s6 + @s7 + @s8 + @s9)
GO

Как легко видеть, данный вариант работает при длине определения view до 80000 символов. Смысл ясен: если необходима еще бОльшая длина, добавьте переменные @s10, @s11 и т.д. Пример для тестирования:

create table VeryVeryLongTableName (a int identity primary key,
b char(10), c char(10))
insert VeryVeryLongTableName (b, c) values ('b', 'c')

create view v as
select * from VeryVeryLongTableName union all
... (250 раз) ...
select * from VeryVeryLongTableName union all
select * from VeryVeryLongTableName

Далее как в предыдущем примере.

По поводу русских названий объектов - без разницы, могут использоваться вполне. Переименованные поля в таблице видятся под своими новыми заголовками в select * from view сразу после его alter.

Нет, у меня SPs при переименовании полей реагируют сразу. Никакой ручной перекомпиляции не требуется:

create table tbl (a int identity primary key, [Поле] char(10), [Чудес] char(10))
insert tbl values ('абра', 'кадабра')
go
create proc MySp as select * from tbl
go
exec MySp

a Поле Чудес
----------- ---------- ----------
1 абра кадабра

(1 row(s) affected)

exec sp_rename 'tbl.[Поле]', 'Field', 'column'
exec MySp

a Field Чудес
----------- ---------- ----------
1 абра кадабра

(1 row(s) affected)