Manual talk:Content table

So, SQL-unfriendly change.

Is it really resonable?

Having an address in this field, rather than a foreign key, allows content to be stored in different locations, such a fields, or a cassandra database.

In fact, the content of the text table is already an address to an external storage machenism on many installations. The plan is to remove this level of indirection, and put the "external store address" that is currently in the text tabvle directly into the content table. See phab:T183490.

Since we were already using a symbolic reference in practice (at least for big instances), the operational extra cost is zero. Since access to actual page content is rare compared to access to the meta-data (and to the rendered content), direct database joins are not a use case.

All this was discussed at length and in detail before the RFC for this schema was accepted two years ago, see Requests_for_comment/Multi-Content_Revisions and phab:T107595.