I recently encountered a similar requirement, and decided to instead go with JSON inside a BLOB.
The advantages of this approach are;
a) the data stored can be different from one row to the next, but it is still structured. Meaning that individual parts can be read, new parts added and so on, all with maximum flexibility.
b) Although I’m using a BLOB, some backends are supporting JSON fields - so it’s possible the backend could then also read the data. Doing so is beyond my paygrade (I’ll leave that to the SQL folks) but certainly the door is open to that.
c) There are no issues when upgrading tables. (Using Strings and OVER makes upgrading really tricky)
d) The field itself remains as Text, meaning it can be inspected easily, and debugging (outside the program itself) is easy.
There are some disadvantages;
a) BLOB support inside Clarion is limited. (I wrote MyTable to take care of this - which includes using the blob data fields on Browses and forms.)
b) It takes “longer” to parse JSON than it does to simple OVER a string. However the time is short compared to the time it takes to actually read the database. So performance lost is minimal, and inconsequential.