Necesitaré algunas consultas en el formulario "enumerar todos los objetos donde uno de los nombres alternativos es 'foobar'". El tamaño esperado de la tabla es del orden de unos pocos millones de registros. Las consultas JSON de Postgres se pueden usar para eso, y también se pueden indexar (Índice para encontrar elementos en la matriz JSON, por ejemplo). Sin embargo, ¿DEBE hacerse de esa manera o es una solución perversa que no se recomienda?
puede hacerse de esa manera, pero eso no significa que debas hacerlo. En cierto sentido, la mejor práctica ya está bien documentada (consulte, por ejemplo, usar hstore, usar XML, usar EAV y usar una tabla separada) con un nuevo tipo de datos que, para todos los efectos prácticos (además de la validación y la sintaxis), no es diferente de opciones anteriores no estructuradas o semiestructuradas.
Dicho de otra manera, es el mismo cerdo de siempre con maquillaje nuevo.
JSON ofrece la posibilidad de utilizar índices de árbol de búsqueda invertida , de la misma manera que lo hacen hstore, tipos de matriz y tsvectors. Funcionan bien, pero tenga en cuenta que están diseñados principalmente para extraer puntos en una vecindad (piense en tipos de geometría) ordenados por distancia, en lugar de extraer una lista de valores en orden lexicográfico.
Para ilustrar, tome los dos planes que describe la respuesta de Roman:
- El que realiza un escaneo de índice recorre las páginas del disco directamente, recuperando las filas en el orden indicado por el índice.
- El que realiza un escaneo de índice de mapa de bits comienza identificando cada página del disco que podría contener una fila y las lee tal como aparecen en el disco, como si estuviera (y de hecho, precisamente como) haciendo un escaneo de secuencia que salta áreas inútiles.
Volviendo a su pregunta:índices de árbol invertido desordenados y de gran tamaño de hecho, mejorará el rendimiento de su aplicación si usa tablas de Postgres como tiendas JSON gigantes. Pero tampoco son una bala de plata, y no lo llevarán tan lejos como un diseño relacional adecuado cuando se trata de cuellos de botella.
El resultado final, al final, no es diferente de lo que obtendría al decidir usar hstore o un EAV:
- Si necesita un índice (es decir, aparece con frecuencia en una cláusula where o, lo que es más importante, en una cláusula de combinación), es probable que desee los datos en un campo separado.
- Si es principalmente cosmético, JSON/hstore/EAV/XML/whatever-makes-you-sleep-at-night funciona bien.
