Re:In MySQL, use “utf8mb4” instead of “utf8” (2016)
by int_19h on Wednesday January 12, 2022 @03:46PM
(#29912438)
It's really weird that they've chosen YAML for it, since its sole (questionable) benefit over the alternatives is that it's geared more towards being edited directly by humans... which is generally not something that you need to do with a database field. JSON is more usual for scenarios like this, not the least because most databases actually provide tools to parse and query it.
[ Parent
| on HN ]
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016)
by marginalia_nu on Wednesday January 12, 2022 @03:56PM
(#29912552)
It's pretty weird to put any configuration-languages in a relational database in general. Large variable-length objects is not what relational databases are good at. You're mostly getting the drawbacks, and very few of the benefits in that use case. Even a filesystem is probably more suitable.
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016)
by capitainenemo on Wednesday January 12, 2022 @04:06PM
(#29912679)
Drupal seems keep a large amount of PHP serialisation of configuration in its database (a JSONish thing), probably because it's the standard data store for the site. Noticed this in fixing a dump one time. Got to use vim's function syntax for regex to ensure the character length count of the string matched the value of the new string.
I think virtually everything generically configurable in the UI that isn't part of a small core with dedicated fields (or in the sitewide PHP config include) is handled that way.
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016)
by int_19h on Wednesday January 12, 2022 @10:17PM
(#29916400)
Most databases have some kind of special support for XML and/or JSON these days. And sometimes you just need to associate structured hierarchical data with each record without knowing the precise schema in advance. If it's non-hierarchical, you can always use a separate key/value table; but tree queries are not exactly convenient (or fast) in SQL.