I'm not exactly sure what you mean by 'instead of that', but basically, a view rarely does anything to improve performance. That is not to say that views are not useful. They help to centralize complicated join logic, and correspondingly simplify those queries that then use that view. They help to provide a database abstraction layer. They do not, however, provide any performance benefits by their simple existence. They *can* affect performance because the optimizer allows you to collapse a view into the surrounding query or not, which *can* be helpful when fine-tuning queries, but this minor benefit is not enough, by itself, to justify the creation of a view. In your case, this benefit would not even apply, since you are talking, I think, about either replacing the table itself with a view, which would buy you nothing, or the 2-table join with a view, which would also buy you nothing. A view does nothing more than provide a storage facility for commonly-used SQL - *not* the results from that SQL. The optimizer will simply take the view's definition and stick it in the SQL statement that uses the view before 'solving' the entire statement.
Hope that made sense.
However, if you are talking about Materialized Views, then that is a different story. A Materialized View *does* store the *results* of the view as an actual result set (table) in the database. If you want to know more about them , check out the Oracle docs, as there are a lot of considerations when using them.