Ich brauche einige Abfragen in der Form "alle Objekte auflisten, bei denen einer der Altnamen 'foobar' ist". Die erwartete Tabellengröße liegt in der Größenordnung von einigen Millionen Datensätzen. Dafür können Postgres-JSON-Abfragen verwendet werden, und es kann auch indiziert werden (z. B. Index For Finding Element in JSON-Array). SOLLTE es jedoch so gemacht werden oder ist es ein perverser Workaround, der nicht empfohlen wird?
Es kann so gemacht werden, aber das bedeutet nicht, dass Sie sollten. In gewissem Sinne ist die Best Practice bereits gut dokumentiert (siehe z. B. die Verwendung von hstore vs. die Verwendung von XML vs. die Verwendung von EAV vs. die Verwendung einer separaten Tabelle) mit einem neuen Datentyp, der sich in jeder Hinsicht und für praktische Zwecke (abgesehen von Validierung und Syntax) nicht unterscheidet von früheren unstrukturierten oder halbstrukturierten Optionen.
Anders ausgedrückt, es ist das gleiche alte Schwein mit neuem Make-up.
JSON bietet die Möglichkeit, invertierte Suchbaumindizes zu verwenden , genauso wie es hstore, Array-Typen und tsvectors tun. Sie funktionieren gut, aber denken Sie daran, dass sie in erster Linie zum Extrahieren von Punkten in einer Nachbarschaft (denken Sie an Geometrietypen) nach Entfernung geordnet sind, und nicht zum Extrahieren einer Liste von Werten in lexikografischer Reihenfolge.
Nehmen Sie zur Veranschaulichung die beiden Pläne, die Romans Antwort umreißt:
- Derjenige, der einen Index-Scan durchführt pflügt direkt durch Festplattenseiten und ruft die Zeilen in der durch den Index angegebenen Reihenfolge ab.
- Derjenige, der einen Bitmap-Index-Scan durchführt beginnt damit, jede Festplattenseite zu identifizieren, die eine Zeile enthalten könnte, und liest sie so, wie sie auf der Festplatte erscheinen, als ob (und tatsächlich genau so) ein Sequenzscan durchgeführt würde, der nutzlose Bereiche überspringt.
Zurück zu Ihrer Frage:Überladene und übergroße umgekehrte Baumindizes wird in der Tat die Leistung Ihrer App verbessern, wenn Sie Postgres-Tabellen als riesige JSON-Speicher verwenden. Aber sie sind auch keine Wunderwaffe, und sie bringen Sie beim Umgang mit Engpässen nicht zu einem angemessenen relationalen Design.
Das Endergebnis unterscheidet sich letztendlich nicht von dem, was Sie erhalten würden, wenn Sie sich entscheiden, hstore oder ein EAV zu verwenden:
- Wenn ein Index benötigt wird (d. h. häufig in einer Where-Klausel oder, was noch wichtiger ist, in einer Join-Klausel vorkommt), möchten Sie die Daten wahrscheinlich in einem separaten Feld haben.
- Wenn es hauptsächlich um kosmetische Zwecke geht, funktioniert JSON/hstore/EAV/XML/whatever-makes-you-sleep-at-night gut.
