Seems to me that the "wrappers" provided by views will allow me to modify the underlying database structure without having to change semantics in my code

... What I am suggesting is that even with tables, there may be an advantage to "wrapping them in a view ... which is also valuable to apply more meningful names to column attributes.

I'm now looking into whether I can create "updateable views" ... modifying attributes in tables in a view that are not involved in PK/FK relationships.

Any feedback on either of those subjects will be appreciated.

Thanks,

Steve

Steve, this thread should be useful to you: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10416

Thanks ... I understand the "how" .... I'm wondering if there are any issues that I need to be aware of before I adopt this approach as a "best practice" .

thx,

Steve

There's a problem with meta-data retrieval for view fields, when it comes to info about nullability, field length etc. Not in all db's but in sqlserver for example it's a problem, as the view data isn't refreshed until the view is dropped/recreated (even though the table meta-data changed). This is documented in sqlserver's docs.

So the meta-data for these aspects isn't retrieved.

You also have to ask yourself: is it worth the effort, to write update triggers etc. for views if you're just wrapping a table? Be aware that you're creating a mapping yourself inside the view, which will require you to extensively document it to make it visible to people who will take over the project for example in a few years and have to maintain it.