You can perform data manipulation on views

use master;
go

create database y_test;
go

use y_test;
go


create table employee
(
id int not null,
name varchar(100) not null,
gross_salary numeric(18,4) not null default '',
password varchar(100) not null default ''
);
go

insert into employee(id, name, gross_salary, password) 
select id, name, gross_salary, password 
from (values
(1, 'Jobs', 75000, 'dashing'),
(2, 'Ballmer', 30000, 'through'),
(3, 'Gatez', 90000, 'the snow')
) as x(id, name, gross_salary, password);
go

select * from employee;
go

create view hr_facing_employee_record as
select id+0 as id, name, gross_salary * (1 - .32 /* Darn Philippines Withholding Tax! */ ) as net_salary from employee;
go

select * from hr_facing_employee_record;
go

delete from hr_facing_employee_record where id = 2;
go

select * from hr_facing_employee_record;
go

-- won't be allowed, inserting records to database must be done in a controlled manner, i.e. must insert directly to table, for example, there might other mechanism how ID is generated/assigned, so must directly insert to table
insert into hr_facing_employee_record(id,name) values(9,'Torvalds');
go

select * from hr_facing_employee_record;
go


update hr_facing_employee_record set name = 'Gates' where id = 3;
go

select * from hr_facing_employee_record;
go


/* 

-- won't be allowed, password is not exposed in hr_facing_employee_record

update hr_facing_employee_record set name = 'Backdoor', password = 'open sesame' where id = 3;
go

select * from hr_facing_employee_record;
go
*/


-- won't be allowed, a view can protect the record integerity
update hr_facing_employee_record set id = 8 where id = 3;
go

select * from hr_facing_employee_record;
go

use master;
go

drop database y_test;
go

Somehow, updateable views is justified (Hello Postgresql! requesting ^_^ ), you can hide the actual table from the user and you can protect what needs to be protected and at the same time abstract some information. However, this problem could also be tackled by using column-level permissions feature of your favorite RDBMS. Each approach has their own appeal.


Sometimes programming into the language has some drawbacks. You won't know what features the alternative products can bring to the table, you sort of missing the proper way of expressing your idea/solution to a given problem domain.

Sql Server Views has updateable views, will keep that in mind, will keep that in mind, or rather in blog ;-)