Even with revisions turned off for a given content type, the field_revision_* tables for the fields each contain a single record that matches the corresponding record in the corresponding field_data_* table.

I've always been aware of this, and previously, I've never had a reason to question it. However, now I am dealing with an extremely large database, and almost 50% of the database size is made up of this duplicated data in the revisions tables.

Why do we duplicate all the field data in the revision tables when revisions are disabled for a content type?

  • There is a module that will remove this data, Field SQL norevisions. This does irreversible things to your database, so beware. It it written by alexpott, so I think it is safe to assume he knows what he is doing. – mpdonadio Jul 12 '14 at 23:14
  • I actually discovered that module yesterday. The 7.x-2.x version was built by the team from Highwire Press who are dealing with similar big data issues. This seems like the solution I will pursue. – BrianV Jul 14 '14 at 13:47

That's a great question - I wonder if it's any different in D8.

The field_data tables, and node table also track the "current vid" which is the current revision id, I guess they felt there had to be at least one. But it does seem like there should be another way to do this. Maybe they could just store a 0 or something as a flag in the field_data tables current_vid column to indicate there's not a revision.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.