News for hackers. Stuff that matters.

A comment on In MySQL, use “utf8mb4” instead of “utf8” (2016). Parent comment

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by marginalia_nu on Wednesday January 12, 2022 @02:09PM (#29911432)
Why were you putting YAML in a relational database?
[ Parent | on HN ]
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by tyre on Wednesday January 12, 2022 @03:08PM (#29912088)
iirc it was to allow customization of an e-commerce item. Basically a column as a document (in the sense of a document database) with custom attributes that could be…large.

It wasn’t my implementation. This was another team

[ Parent | on HN ]
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.
[ Parent | on HN ]
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.

[ Parent | on HN ]
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.
[ Parent | on HN ]
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by folmar on Wednesday January 12, 2022 @07:13PM (#29914870)
Postgres is really happy with xml or json, as you please, and saves you from the complexity of having another data store.
[ Parent | on HN ]
Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by mrweasel on Wednesday January 12, 2022 @03:40PM (#29912383)
Maybe also do a checksum or something, seriously it could just be CRC32. I get that it's not something you instinctively think to do. For configurations that are most likely parsed directly by something else though, may check that nothing broke in transit.
[ Parent | on HN ]