Remove "@todo In theory we should use the data table as base table, as this would" from EntityViewsData

I'm assuming this is about the optimization we discussed in #1857256: Convert the taxonomy listing and feed at /taxonomy/term/%term to Views, i.e. getting rid of the node table in this query:

SELECT taxonomy_index.sticky AS taxonomy_index_sticky, taxonomy_index.created AS taxonomy_index_created, node.nid AS nid, node_field_data.langcode AS node_field_data_langcode FROM node node INNER JOIN taxonomy_index taxonomy_index ON node.nid = taxonomy_index.nid INNER JOIN node_field_data node_field_data ON node.nid = node_field_data.nid WHERE (( (taxonomy_index.tid = :taxonomy_index_tid) )) ORDER BY taxonomy_index_sticky DESC, taxonomy_index_created DESC LIMIT 11 OFFSET 0

Having potentially 4 tables exposed to Views (entity base table, field data table, revision table, and revision field data table) is overkill and also is confusing in the UI. For instance, Node now has 4 node ID fields/filters showing, since the 'nid' field appears on all of these tables, but the values are actually the same since the tables are joined on nid.

So what we should do here is:
- Generically use the data table and revision data table, and omit the base and revision tables.
- If there are fields being used on the base table that are not in the data table, join the base table. I think this is only UUID, so perhaps make a special case for UUID... and look at the way the entity schema is being created to see if there is anything else?
- There are some revision fields that are only on the revision and not on the revision field data tables: timestamp, uid, and log message. If these are exposed to views, we'd need to join in the revision table.
- We also need a special case for langcode. There are potentially 4 different langcode values, because the values on the base/revision tables are "original" language for that revision, and on the field data tables they are "translation" languages for that revision. So we probably need to have all 4 langcode fields available, if they exist on the entity. Node does not have langcode on the base table, but taxonomy does. Why I am not sure... again looking at the logic of how the database schema is being generated may be helpful?

I also think we should fix this sooner rather than later. The UI is pretty confusing as it is, so I'm changing it to a major bug rather than a normal task.

We can maybe fix the UI issues fairly easily by removing the UI-exposed field/filter/argument/sort for the NID and VID fields from the base tables, and instead using the field data tables?

base table is good for "count" queries when no language is involved

@andypost: Can you give an example of where Views is doing this? And without also joining in the data table?

there was some in handlers... faced when converted queries by making entities multilingual

Um... that's a bit vague for me. What type of handlers? And do they still exist in current 8.0.x code?

the grouping at least is "black-box" for me, the related #2239227: Views GroupwiseMax class calls protected properties

I think this issue is related to #2273849: Convert INNER joins to LEFT joins for relationships without "Require this relationship". The problem there is that relationships can be marked as Required or not. When we use an inner join to connect the node and node_field_data tables (for example) it has the effect of making the relationship required, no matter whether the option is checked or not.

We forgot to remove the @todo in that issue, let's do it here :)

Dcos are not frozen in beta. Committed 78c71b4 and pushed to 8.0.x. Thanks!