Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Merci à vous deux.
Bonjour,
Oui je suis parti sur cette option là (schema central + schema / client), j'ai en effet remarqué dans mes recherches que l'inter base est assez couteux (que ce soit dblink ou postgres_fdw).
Pour mon information, quelle la taille de votre base de données (sans être forcément précis, plutôt une mesure comme "quelques dizaines de Mo / Go"...) ?
Merci par avance,
Oui la communication inter bases n'est pas encore très souple, malgré l'arrivée de postgres_fdw (qui est bien utile quand même).
D'un point de vue application / développement, l'inter schémas est le plus simple à maintenir. L'interrogation reste sur les performances, mais à priori en cherchant pas mal d'infos sur le net, pas grand impact avant plusieurs go par schéma.
Bonjour,
Il ne me semble pas avoir trouvé de discussion sur ce sujet.
J'ai une problématique simple sur une application :
- Une DB "mère" dans laquelle se retrouve des infos "globales"
- Une DB par client. Chaque DB client est identique.
Ma question est donc simple. D'un point de vue performance vaut-il mieux une DB avec un schema public par client, ou une seule DB avec un schema par client ?
D'un point de vue montée en charge des données sur un schema, quel serait l'impact sur les autres schema puisqu'ils seraient dans la même DB ?
Après plusieurs recherches sur internet, ça reste assez vague... Une idée globale semble sortir tout de même, la méthode multiple DB est "ancienne", alors que la multiple schema est "moderne".
Mais rarement de discussion sur les performances.
Merci par avance,
Merci Marc.
Pour infos, j'ai eu ceci également :
WITH T1 AS
(
SELECT (ARRAY[NULL, true, NULL])[k] as Val1, k
FROM generate_series(1,array_upper(ARRAY[NULL, true, NULL],1)) k
)
SELECT k FROM T1 where val1 = true
Je vais tester les deux, et comparer les performances.
Bonjour la communauté,
Comme je l'indique dans le titre, je souhaiterai récupérer la clé d'un array (ou position) à partir de sa valeur qui est unique.
Voici un exemple :
Mon Array est {NULL,true,NULL}
Je souhaite récupérer la positon de true, soit 2
Le problème est que ce tableau n'a pas de taille connue (n élément), sinon je me serai débrouiller avec un CASE/WHEN.
Merci d'avance pour vos réponses,
Oui c'est vrai que je pouvais tester rapidement.
Donc effectivement, dans une fonction récursive, appeler un RAISE NOTICE peut vite devenir couteux.
Merci beaucoup pour cette démonstration.
Bonjour,
Une question de "culture", je sais que les RAISE NOTICE représente un certains coût (je m'efforce de tous les supprimer après debug), mais qu'en est-il exactement ?
A t-on une idée plus ou moins précise du coût engendré et donc de la perte de performance ?
Merci d'avance.
Non du tout 
. Il n'y a aucune clé étrangère (c'est la première fois que je suis confronté à ce genre de chose). Le principe est de gagner énormément en performance car il n'y a aucune jointure quand on interroge la bdd.
La base (modele+requête arbre) nous a été fournit. Donc la base est déjà conçue. J'avais déjà au fournisseur demandé pour les clés (car jamais vu auparavant), et c'est bien confirmé. C'est le principe de l'arbre SQL.
Oui c'est assez compliqué à expliquer. Avec plus de détail :
Ma fonction récursive m'affiche l'arbre de toute l'application. Exemple :
La classe adresse est lié à la classe code postal : adresse/codepostal (en partant du nœud adresse). Comprendre "adresse a un code postal"
La classe adresse est lié à la classe département : adresse/departement(en partant du nœud adresse). Comprendre "adresse a un département"
Les classes sont renseignées dans une table (ce qui me permet de faire ma récursivité). Toutes les classes renseignées dans cette table correspondent à une table (Ex : la classe adresse correspond à la table t_adresse, la classe codepostal à la table t_codepostal... Etc.).
Ce qui me bloque, c'est savoir maintenant comment lier cet arbre aux données (je sais qu'une adresse à un code postal, mais savoir quelle adresse à quel code postal).
Bonjour,
Je reviens vers vous pour étoffer mes connaissances et mon appli.
J'ai une fonction récursive qui me dessine l'arbre de l'application. Pour se faire j'ai une table qui rassemble toutes les classes (à chaque classe correspond une table, Ex : la classe adresse et la table t_adresse).
Pas de souci, l'arbre est ok. Par exemple :
Noeud adresse qui possède deux feuilles : code postal et département.
Maintenant question simple , comment lier cet arbre (construit avec les classes) aux données ? Exemple concret : Comment retrouver le code postal et le département de mon adresse d'id 20, à partir de cet arbre ?
Évidemment il n'y a aucune clé étrangère dans l'application.
Merci d'avance,
Et oui je viens de voir ça...
Merci.
Voici ce que retourne mon "SELECT version()" :
"PostgreSQL 8.1.21 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)"
WITH n'est pas implémenté en 8 peut-être ?
Mon pgadmin3 est la dernière, la 1.12.1 (installé sous un windows).
Merci d'avance.
Bonjour,
Merci à vous. Aujourd'hui plusieurs tests, j'ai retapé la ligne à la main pour être sûr, même souci...
N'y a t-il rien d'autre à déclarer avant, ou autoriser ?
Merci d'avance.
EDIT : En testant avec l'exemple suivant, même constat :
WITH RECURSIVE t(n) AS (
SELECT 1
UNION ALL
SELECT n+1 FROM t
)
SELECT n FROM t LIMIT 100;Bonjour à tous,
Je souhaite exécuter une assez grande requête dans pgadmin, qui démarre par un WITH :
WITH w_nom AS(
Il s'arrête à l'exécution dès cette première ligne avec l'erreur
"ERREUR: erreur de syntaxe sur ou près de « WITH »
État SQL :42601
Caractère : 3"
Impossible de trouver une solution...
Avez-vous une idée du problème ?
Merci d'avance,
Pages : 1