The table #__fields_values is not normalized.
In simple words we have repetition of information (value
) between this table's rows and the #__fields table.
The inserted values seem to be stored as a json string in the fieldparams column of the #__fields table
{"multiple":"","options":{"__field10":{"name":"Computer Science","value":"Computer-Science"},"__field11":{"name":"History","value":"History"},"__field12":{"name":"Poltics","value":"Poltics"}}}
This is jeopardising the referential integrity of the data, as the only responsible for that, is the code used for saving them.
E.g. If we made a change in a value, this change has to be reflected in all the tables, where that value is present.
Create 1 more table for the values, where each value will be saved and will have a primary key.
Then use the PK as a foreign key to the table _#_fields_values (or wherever they are used).
This requires changes in the code level beyond the schema changes. Is this a long shot atm?
Not sure if it will cause any B/C issue or any other issue (e.g. with the plugins).
I can prepare a PR for that, in case you agree in principle.
Labels |
Added:
?
?
|
That would only work for fields which have predefined values (eg lists, checkboxes), right?
Fields like text or number don't have a reference that could be used.
I'm also not really convinced that the stored values need to be updated if you change the field options. Those field values are not meant to have referential data integrity. That's not the purpose of those fields.
Appendum:
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-07-31 09:26:51 |
Closed_By | ⇒ | sakiss |
I am closing it as the fields scope seems to be broader than i initially thought.
I will reconsider that.
A pr would be good, but you have to do it for J4.