>I'v heard is said that there should be a view in the DBC for each table.
>
>[] Is this right?

I think yes - meaning there probably was someone who said that once :).

Is that the right thing to do, I have some doubts. Views for views' sake? I don't see a reason. Do you create a table you don't need? Then why would you create a view you don't need.

>[] What purpose would this serve.

A proof-of-concept for the bright idea of the person who said that in the first place?

Actually, the good reason may be the groundwork for later upsizing: to have a view on each table, each table then has to have a viable primary key; once you have a view, it's quite easy to replace such views with remote views, and thus the upsizing can be done in a day, more or less. In this layout, it makes sense.

However, if you don't have any plans to move your tables to a DB server, or already use one, or want to do SPT instead of views, then I don't see a good reason for this.

>[] What happens when the underlying structure change?

Keep the views in a separate dbc, do a gendbc() on it, and re-run the generated code whenever your structures change. Takes just a second to run.