If you make a View that contains Field.module fields (for display, not for Sort or Filter criteria), the views_handler_field_field class loads every entity within the view and then just pulls out the needed values for display.
As far as I know, this architectural decision was made to avoid the MySQL JOIN limit on tables (61). However, most views won't get near to that many JOINs. We may be able to get a major efficiency improvement on field listings if we intelligently determined how many JOINs were going to be used, and only resort to loading all entities if nearing the limit.
There may be other problems with some fields that assume that they get the entire node, which may need to be adjusted. Let's do some research on if this is possible and/or worth it from a performance perspective.
Recent comments
Thank you very much for your fast answers and clear explanations ! I understand that the site is not corrupted and that there is no danger in leaving the code and the database in their...
Base table or view not found upgrading to 1.32.0, TRUNCATE {cache_book}
Until the official new release (coming soon), the error will ALSO show up when you clear caches, unless you fix this manually as above.
Base table or view not found upgrading to 1.32.0, TRUNCATE {cache_book}
If you want to try to fix it yourself now, I think you can manually set the schema version for the book module (in the system table) to 7000, and then try running the updates again. Test on a...
Base table or view not found upgrading to 1.32.0, TRUNCATE {cache_book}