das was Du mir da als Link geschickt hast, ist mir zu hoch.
Das kann ich nicht recht glauben. Du hast wahrscheinlich zu kurz drauf geschaut
Es ist eine sehr bequeme Art-wenn nicht sogar faule-, JSON zu lesen.
Ohne es verstehen zu müssen: Ein einziges
SQL Select Statement liefert Dir alle Felder, die Du aus dem JSON brauchst/haben möchtest, ohne Substring-Krieg und Frickelei.
Ich kenne Deinen Bedarf an Feldern aus dem books Schema nicht, aber ich behaupte, dass man mit einem Select alles auslesen kann, was benötigt wird.
Mein Beispiel enthält natürlich nur 5 Felder und die sind nicht mal alle aus dem books schema.
Ganz generell mal die Anmerkung, dass natürlich mit der Existenz eines Hammers nicht jedes Problem zu einem Nagel gemacht werden kann. Mein Vorschlag
SQL zu nutzen macht nur unter bestimmten Bedingungen Sinn. Wenn sowieso
SQL genutzt wird, wenn tatsächlich viele oder sehr viel Daten bewegt werden.
Am Ende ist es wahrscheinlich egal, welchen Weg man geht, um JSON zu lesen oder zu schreiben. Die Botschaft ist hauptsächlich, dass man eine geeignete, erprobte Libary/
Unit dafür nimmt, statt mit substr usw. zu Fuß rumzueiern. Mein Vorschlag ist hier halt PostgreSQL.
Wenn Dir
SQL nicht fremd ist, dann ist Postgres natürlich nicht automatisch an Bord bzw. im Projekt und sicher "Kanonen auf Spatzen". Ich habe es nur genommen, weil es das kann und ich es häufig nutze. Als kleiner, feiner Ersatz könnte auch SQLite dienen. Dessen JSON Funktionen sind aber irgendwie anders gestrickt.