Si encuentras alguna parte que te causa duda puedes dejarlo en los comentarios y te responderemos tan rápido como podamos.
Solución:
El C colación es la elección correcta.
Todo es un poco más rápido sin configuración regional. Y dado que ninguna intercalación es correcta de todos modos, cree la base de datos sin que colación, es decir, con C.
Puede ser una molestia tener que proporcionar una colación para muchas operaciones. Sin embargo, no debería haber una diferencia notable en la velocidad entre la intercalación predeterminada y una intercalación ad-hoc. Después de todo, son solo datos sin clasificar y las reglas de clasificación se aplican al clasificar.
Tenga en cuenta que Postgres se basa en la configuración de configuración regional proporcionada por el sistema operativo subyacente, por lo que debe tener configuraciones regionales generadas para cada configuración regional que se utilizará. Más en la respuesta relacionada sobre SO aquí y aquí.
Sin embargo, como @Craig ya mencionó, índices son el cuello de botella en este escenario. La intercalación del índice tiene que coincidir con la intercalación del operador aplicado en muchos casos que involucran datos de caracteres.
Puedes usar el COLLATE especificador en índices para producir índices coincidentes. Los índices parciales pueden ser la opción perfecta si está mezclando datos en la misma tabla.
Por ejemplo, una tabla con cadenas internacionales:
CREATE TABLE string (
string_id serial
,lang_id int NOT NULL
,string text NOT NULL
);
Y lo que más le interesa es un idioma a la vez:
SELECT *
FROM string
WHERE lang_id = 5 -- 5 being German / Germany here
AND string > 'foo' COLLATE "de_DE"
ORDER BY string COLLATE "de_DE";
Luego crea índices parciales como:
CREATE INDEX string_string_lang_id_idx ON string (string COLLATE "de_DE")
WHERE lang_id = 5;
Uno para cada idioma que necesites.
Realmente, herencia podría ser un enfoque superior para una tabla como esta. Luego, puede tener un índice simple en cada tabla heredada que contenga solo cadenas para una sola configuración regional. Por supuesto, debe sentirse cómodo con las reglas especiales para las tablas heredadas.
Le sugiero que elija una intercalación que proporcione el orden Unicode predeterminado. De esa manera, obtiene resultados sensatos incluso si no anula la intercalación en cada consulta. Desafortunadamente, la mayoría de los sistemas operativos (¿todos?) no proporcionan una configuración regional que simplemente se denomine “Unicode predeterminado” o algo así, por lo que tendrá que adivinar y/o investigar una buena opción. Por ejemplo, en Linux/glibc, las configuraciones regionales de_DE.utf8 o en_US.utf8 simplemente pasan por el comportamiento predeterminado, por lo que ambas son buenas opciones.
No creo que usar la configuración regional C sea una buena idea, porque entonces el comportamiento predeterminado de su aplicación será inútil. Y es posible que no obtenga el comportamiento adecuado de las operaciones de conversión de casos.
(Anular la intercalación en una consulta no tiene mucha sobrecarga. Es solo una operación de tiempo de análisis).
Calificaciones y comentarios
Puedes auxiliar nuestra labor escribiendo un comentario o dejando una valoración te lo agradecemos.