J'aurai besoin de quelques requêtes sous la forme "liste de tous les objets où l'un des altnames est 'foobar'." La taille de table attendue est de l'ordre de quelques millions d'enregistrements. Les requêtes Postgres JSON peuvent être utilisées pour cela, et elles peuvent également être indexées (Index For Finding Element in JSON array, par exemple). Cependant, cela DEVRAIT-il être fait de cette façon ou s'agit-il d'une solution de contournement perverse qui n'est pas recommandée ?
Il peut être fait de cette façon, mais cela ne signifie pas que vous devriez. Dans un certain sens, la meilleure pratique est déjà bien documentée (voir par exemple utiliser hstore vs utiliser XML vs utiliser EAV vs utiliser une table séparée) avec un nouveau type de données qui, à toutes fins pratiques (en plus de la validation et de la syntaxe), n'est pas différent à partir d'options antérieures non structurées ou semi-structurées.
Autrement dit, c'est le même vieux cochon avec un nouveau maquillage.
JSON offre la possibilité d'utiliser des index d'arborescence de recherche inversés , de la même manière que hstore, les types de tableau et les tsvectors. Ils fonctionnent bien, mais gardez à l'esprit qu'ils sont principalement conçus pour extraire des points dans un voisinage (pensez aux types de géométrie) classés par distance, plutôt que pour extraire une liste de valeurs dans l'ordre lexicographique.
Pour illustrer, prenons les deux plans décrits dans la réponse de Roman :
- Celui qui fait un balayage d'index parcourt directement les pages du disque, en récupérant les lignes dans l'ordre indiqué par l'index.
- Celui qui effectue une analyse d'index bitmap commence par identifier chaque page du disque susceptible de contenir une ligne et les lit au fur et à mesure qu'elles apparaissent sur le disque, comme s'il s'agissait (et en fait, exactement comme) d'effectuer une analyse de séquence qui ignore les zones inutiles.
Pour en revenir à votre question :des index d'arborescence inversés encombrés et surdimensionnés améliorera en effet les performances de votre application si vous utilisez des tables Postgres comme magasins JSON géants. Mais ils ne sont pas non plus une solution miracle, et ils ne vous mèneront pas aussi loin qu'une conception relationnelle appropriée face aux goulots d'étranglement.
L'essentiel, en fin de compte, n'est pas différent de ce que vous obtiendriez en décidant d'utiliser hstore ou un EAV :
- S'il a besoin d'un index (c'est-à-dire qu'il apparaît fréquemment dans une clause where ou, plus important encore, dans une clause de jointure), vous souhaiterez probablement que les données se trouvent dans un champ séparé.
- Si c'est principalement cosmétique, JSON/hstore/EAV/XML/whatever-makes-you-sleep-at-night fonctionne bien.
