Hi,

I have an application with a DB backend and I need to design views for the database. The way I understand it, views are good for two things:

- using access conditions in the where clause to restrict users from seeing rows they are not supposed to see

- cutting out attributes / coloumns which they don't need / should not see.

But I am finding it hard to decide which attribute a user needs. Say I have a table like Country(country_id, country_name, country_iso_code, language_id, currency_id).
The application would present the user only with name, iso-code, language and currency, but not with the IDs. However the application will need the IDs to provide this information. So, in this example, would you include the ID coloumns within the user view or would the view just present a join of all these attributes?

Thx.

All requirements for your database design are driven by the applications. If the application needs an attribute, it must be part of the view definition - even if this attribute is used for application-internal processing only.

Btw, there are other uses for views:

• separating the internal implementation of tables and the logical view presented to applications (e.g. you can denormalize 2 tables into a single table for fast access in some cases, but still provide 2 views that have the logical schema of the original tables - the application doesn't care what you have done under the covers)
• access control on views is independent of the access control on the underlying tables
• you can pre-formulate queries that join multiple tables
• ...

Thanks Stolze, that's exactly what I needed to know.