Fonction : query+string to array+comparaison des tableaux

Bonjour,

Je débute en postgres que je vais utiliser pour un entrepôt de données à côté de ma base principale, avec un autre sgbd. La structure est simple, mais la volumétrie va être élevée. C'est assez élevé pour justifier qu'une table indicateur (qui est déjà le résultat d'un calcul) dispose d'un champ qui concatène des clés primaires. Celles ayant servi pour le résultat.
Or, je cherche une solution propre pour effectuer de multiples croisements. Exemple :

Indicateur 1 : "Total avec des machins" pour la période 201512 qui vaut 4 et clés primaires 1900,1870,3052, 4012
Indicateur 2 : "Total avec des trucs" pour la période 201512, qui vaut 2 et clés primaires 1900,4012

J'imagine procéder en créant une fonction qui effectuera ma query, puis dans une boucle, un string to array. Puis comme je le vois dans la doc de postgres je pourrais faire ceci :

arrayRowNmoins1[1900,1870,3052, 4012] && arrayRowN[1900,4012]

Et ensuite retourner le résultat qui serait donc dans le cadre de l'exemple "Total avec des machins et des trucs" (valeur 2 et clés 1900,4012).

Question, ma démarche est-elle la bonne ?
Car je ne vois pas comment je peux faire par simple query. D'autre part, sans demander le code exacte, comment je code ça ? Pas la query, juste la loop et le return !

D'avance merci !

Aucune des méthodes n'est la bonne. En effet, PostGreSQL n'est pas du tout optimisé pour faire de l’entrepôt de données surtout si vous annoncez de forte volumétrie.
Avoir une clef concaténée qui résulte de multiples clef va conduire à une clef trop longue inefficace.
Avoir une clef composite sur des compositions variantes (vous pouvez ajouter une colonne de discrimination dans votre clef pour savoir d’où vient cette clef) va conduire à une meilleure organisation pour des recherches précises mais ne supportera pas non plus une charge importante, car l'optimiseur de PostgreSQL ne sait pas optimiser le "star join"....

Autrement dit, la seule solution viable est d'opter pour un SGBDR plus indiqué pour cela comme Oracle, SQL Server ou Terradata.

Quel serait la volumétrie en nombre de lignes et d'octets ?
Quel est le temps de réponse souhaité ?

A +

Bonjour,

Et merci pour votre réponse !
On ne joue pas dans la même catégorie : quand j'annonce volumétrie élevée, c'est sans commune mesure avec ce que vous devez connaître.
Si j'ai 10^6 indicateurs par an, ce sera le bout du monde. Et en disant celà, c'est dans l'optique de signer un client à la limite de notre système.
Pour le cas actuel, ça se situera aux alentours de 250k à 300k par an.
Après, je ne souhaite pas que ces indicateurs soient stockées dans la base principale.
Quant aux clés concaténés, pour un indicateur annuel, on se situerait aux alentours de 4000 clés.

Voilà, navré de ne pas avoir précisé ça et annoncé d'emblée "volumétrie élevée".

Dans ce cas là, ça devrait tenir la route, mais prévoir TRES large en terme de cache (RAM 64 Go par exemple...) à voir

A +