TYPO3 Core

Background/Use Cases:
We have a bunch of sites from larger clients that "require" an oftentimes almost excessive amount of custom CTypes.

If I'm understanding correctly, the "TYPO3 way" to implement this on the DB side would be to reuse existing tt_content columns where applicable. E.g."image" for an image, "bodytext" for an RTE, et cetera. I would then add additional columns where necessary. So if I needed two images in one CType for example, I would add a column like this: "custom_image_1".

Naming the columns semantically makes sense for standard columns, but doesn't seem practical for the custom scenario:

Imagine a case where we have 3 CTypes. The first one needs a custom checkbox, the second one a radio button and the third one a number input. If we were to name these semantically, we would create 3 columns "custom_checkbox_1", "custom_radio_1" and "custom_number_1".

Now imagine the first element needs another checkbox: We would have to create another column "custom_checkbox_2", even though we'd have 2 free columns of the same datatype available already (from the radio and the number input).

If we were to to name them by type instead, this scenario could be avoided and we'd have a cleaner DB for it. We'd simply create one field "custom_int_1", and then once one CType needs two ints we'd create the next one "custom_int_2", and so on... Implementation of the field would be done via TCA overrides. We cannot do this however, because DataHandler doesn't respect columnsOverrides.

On the small scale the "problem" might not seem like a big deal, but with a few larger CTypes this gets pretty stupid pretty quickly. We've had cases with 30+ custom columns, that could've probably been less than 10, if we had been able to use the naming by type. Aside from personal preferences, this also seems technically superior to me. There should be (allthough minor) performance implications from creating that many columns, plus the theoretical risk of hitting the row size limit at some point.

Request:
Make it possible to implement the type based "custom column naming" consistently, by supporting columnsOverrides in DataHandler.