What it would be more efficient (real example has all tables with more columns) to use. Two queries or one query containing a subquery? Is this a case where making use of views may considerably help?
If you're going to fetch all of the data anyway, I usually start with one query and see if there's a problem. Using multiple queries just makes the database perform more round trips and makes it construct and optimize the queries separately, and all of that takes time. You can help reduce the time by doing things like trying to fetch on primary keys and using precompiled queries (the details vary depending on what database system you're using) but there will always be extra overhead in multiple queries.
Views are mostly to restrict the fields in a query's results. That can be useful if you want a user to see only some fields in a table (for example, see customer contact info but not credit card info).
It can also simplify the code. For example, you can define a view that performs some sort of query and then the code can simply fetch using the view so it doesn't need to know how the view is built.
But I don't think either of those really helps with performance. (Unless perhaps they can be precompiled somehow. That would probably depend on the database system.)
Regarding the question I post yesterday, it was mentioned as solutions (1) a big query or (2) subsequent queries. Isn't possible to use UNION and put together two queries in one load? Does this option present any advantage to a series of queries?
It's possible that a single query that uses a union might be faster than multiple queries, particularly if you would need to (for example) perform one sub-query for each of a large number of main queries. (I.e. for each company, fetch the jobs posted by that company.)
I *think* what the database could do would be to compile the sub-query and then execute it separately for each of the returned companies. That would be faster than performing the sub-queries from scratch each time.
But I don't know whether a particular database would be smart enough to figure that out (I suspect most would). And you could do the same thing yourself, which would improve your performance. There would still probably be an advantage to making only one round trip, but even there it may depend on the amount of data. If the whole thing returned 20 GB, you might want to fetch and process it in chunks rather than trying to fetch everything all in one go.
I think these sorts of issues are no problem for 95% of typical databases. For the others where this might be an issue, I would prefer to make some quick tests on realistic sized databases to see what actually happens. Some databases are surprisingly good at handling situations that your intuition may say would cause a problem. If you can find out for certain quickly, you may be able to avoid a lot of unnecessary work.