Vous n'êtes pas identifié(e).
Pages : 1
Pour finir, comme je l'ai dit précédemment postgres ne gère pas les datalink.
Ah ok, j'avais mal lu.
Merci encore pour ces précisions.
Arnaud.
Tout simplement, postgres (comme la plupart des autres moteurs de données) ne vont pas bien gérer le stockage d'objets volumineux en base, car c'est n'est pas prévu pour. Vous pouvez cependant le faire, vous n'aurez aucun problème de fiabilité, juste portentiellement des problèmes de performances différents.
Au passage, le standard SQL/MED (et plus particulièrement la partie datalink, voir https://wiki.postgresql.org/wiki/DATALINK) permet de s'affranchir du problème en utilisant le stockage disque standard pour cela, avec le même principe que pour la base(ACID), mais très peu de moteurs l'implémentent (ce n'est pas le cas de postgres).
Merci de ces informations.
NB : il y une parenthèse indésirable en fin de votre lien, le bon lien est https://wiki.postgresql.org/wiki/DATALINK
Je précise que je n'affirme pas que cela ne pose pas de problèmes de stocker des fichiers volumineux en base, mais uniquement que je n'ai pas encore lu d'argumentaire convainquant étayant ce point.
Vous dites "potentiellement des problèmes de performance différents", mais pouvez vous préciser ? (ce n'est pas une critique, simplement avez vous des éléments factuels ou un lien mettant en évidence ces problèmes ?).
Concernant les fonctionnalités DATALINK, je n'arrive pas à trouver la partie correspondante dans la documentation officielle Posgtres. Est ce implémenté ?
Arnaud.
Bonjour et merci de l'intérêt porté à ce sujet.
L'idée de stocker les images hors de la base est liée à la lecture d'autres discutions dans lesquelles il est déconseillé de stocker un grand nombre d'image dans une base SQL pour des raison de fiabilité.
Je vais néanmoins continuer à le faire, les autres possibilités étant assez complexes à priori.
Merci à tous.
Si j'ai fait cette remarque, c'est que j'ai effectivement lu à plusieurs reprises des posts déconseillant de stocker dans la base (et ce concernant différents SGBD), mais j'y ai rarement vu associées des argumentations techniques pertinentes.
De mémoire, les principaux arguments avancés étaient :
- "ne pas alourdir la base" (qu'est ce que cela veut dire ?)
- "la base devient trop volumineuse et les sauvegardes aussi" (ben de toutes façons ça occupera de l'espace de stockage. On ne souhaite pas les sauvegarder ? hé bien donc les exclure dans pg_dump)
Arnaud.
Bonjour,
Merci de vos réponses.
Il s'agissait effectivement tout bêtement de requêtes envoyées par pgAdmin, que je consultais après chaque requête envoyée par l'application cliente...
Par ailleurs, cela m'a permis de me rendre compte que l'application cliente envoyait également, en plus de la requête générée par le code applicatif, un grand nombre de requêtes "système", pour obtenir la liste des tables, la liste des colonnes, leurs types.. etc... et ce à chaque requête !
Pour information, il s'agit du driver postgresql fourni avec le produit Windev, qui ne semble absolument pas optimisé.
@ruizsebastien : non, je suis sur Windows.
Arnaud.
Bonjour,
Par curiosité, pourquoi cette volonté de ne pas stocker les documents directement dans la base ?
Si l'on utilise une base de données, c'est pour y stocker des données, non ?
Cdlt, Arnaud.
Bonjour,
Je souhaite logger uniquement les requêtes envoyées par l'application cliente à la base.
Je constate que mon fichier de log comporte de nombreuses requêtes qui ne sont pas envoyées par le client.
Exemple, ici, seule la 1ère ligne correspond à une requête envoyée par le client :
2014-12-11 18:46:16 CET LOG: instruction : select * from "T_ASS_SINISTRE_SIN";
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,24) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,14) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,24) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1083
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,84) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,84) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 25
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 25
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 21
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 25
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 25
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,7) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 21
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 21
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1082
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 700
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 1700
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,54) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,14) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 23
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 25
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,54) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,14) as typname FROM pg_type WHERE oid = 1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 25
2014-12-11 18:46:17 CET LOG: instruction : SELECT format_type(oid,-1) as typname FROM pg_type WHERE oid = 16
2014-12-11 18:46:17 CET LOG: instruction : SELECT CASE WHEN typbasetype=0 THEN oid else typbasetype END AS basetype
FROM pg_type WHERE oid=23
2014-12-11 18:46:17 CET LOG: instruction : SELECT CASE WHEN typbasetype=0 THEN oid else typbasetype END AS basetype
FROM pg_type WHERE oid=23
2014-12-11 18:46:17 CET LOG: instruction : SELECT CASE WHEN typbasetype=0 THEN oid else typbasetype END AS basetype
FROM pg_type WHERE oid=1043
2014-12-11 18:46:17 CET LOG: instruction : SELECT CASE WHEN typbasetype=0 THEN oid else typbasetype END AS basetype
FROM pg_type WHERE oid=1043Vous conviendrez que cela fait beaucoup de lignes pour un simple select...
Mon serveur est en 9.4beta2 64 bits sur Windows 8.
Les paramètres que j'ai activé dans pgconf sont :
log_destination = 'stderr'
logging_collector = on
log_statement = 'all'
log_min_messages = 'log'
client_min_messages = 'error'J'ai essayé plusieurs niveaux pour log_min_messages mais en vain.
Auriez vous une piste ?
Arnaud.
Je viens de relire ce vieux post, et finalement ce qui m'étonne le plus, c'est qu'un tel échange provienne d'une question posée par ma stagiaire... qui a dû être bien étonnée des réactions suscitées par son innoncente question.
Cdlt, Arnaud.
Merci !
Je n'avais pas pensé aux domaines...
C'est typiquement l'usage que je vais en faire.
Encore merci et bravo pour la qualité des réponses de ce forum.
Cdlt, Arnaud.
Bonjour,
Merci pour cette confirmation.
Après consultation de la doc, je ne trouve pas d'exemple d'une telle contrainte
J'ai trouvé sur la FAQ PG de developpez.com l'exemple suivant :
ALTER TABLE matable
ADD CONSTRAINT numerotel_check CHECK (numerotel ~ '^[0-9]{10,}$'::text);Est la bonne façon de procéder ?
D'avance Merci.
oui
Bonjour,
Est il possible dans pg de mettre en place des contraintes CHECK basée sur une expression régulière ?
C'est à dire que la contrainte serait violée si la valeur insérée ne satisfait pas à l'expression régulière ?
D'avance merci.
Cdlt, Arnaud.
Merci beaucoup !
Effectivement, c'est très pratique.
Du coup, on a pu constater qu'il fallait utiliser la fonction pg_get_indexdef
Par exemple :
SELECT pg_get_indexdef(indexrelid) FROM pg_index WHERE pg_index.indrelid = 'T1'::regclassdonne la définition des index, avec entre autres les noms des composantes à jour.
SELECT pg_get_indexdef(indexrelid, 1, false) FROM pg_index WHERE pg_index.indexrelid = 'monindex'::regclass...permet d'obtenir le nom de la 1ère composante de l'index.
Grand merci à vous deux.
Cdlt, Arnaud.
Bonjour,
Merci de cette réponse très claire.
\d T1 donne effectivement les noms des index avec leurs composantes exactes.
Mais dès lors, comment fait-on pour obtenir par une requête le nom des composantes d'un index ?
Car si on interroge pg_attribute, on a donc le risque d'avoir des noms de colonnes qui ne sont plus à jour.
Or nous avons justement besoin de connaitre les composantes des index, afin de les comparer avec les index définis dans un outil de modélisation et ainsi de décider de supprimer et recréer l'index s'il n'est plus à jour (par exemple s'il ne porte plus sur le mêmes composantes).
Merci par avances de vos conseils.
Cdlt, Arnaud.
Bonjour,
Nous sommes en train de faire des tests sur posgresql 9.1.2 (nous n'avons encore aucune base pg en production, nous "découvrons" le produit) et nous constatons le comportement suivant qui (a priori) nous surprend :
- soit une table T1 avec une colonne C1 et un index simple sur C1 créé comme suit :
CREATE TABLE T1 ( C1 varchar (10)) ;
CREATE INDEX NDX_TEST ON T1 (C1);résultat : on a dans les tables systèmes :
dans pg_class : une table de nom T1 et un index de nom NDX_TEST : OK
dans pg_index : un index rattaché aux 2 enregistrements dans pg_class (pg_index.indrelid = oid de la table dans pg_class et pg_index.indexrelid = oid de l'index dans pg_class) : OK
dans pg_attribute : une ligne avec attname = 'C1' correspondant à la colonnne de la table et un autre ligne avec attname = 'C1' correspondant à la colonne indexée (apparemment une colonne est présente dans pg_attribute en tant que colonne + autant de fois qu'elle est indexée) : OK
- on renomme la colonne C1 :
ALTER TABLE RENAME COLUMN C1 TO C1_TOTO ;résultat :
- la colonne est bien renommée 
- dans pg_attribute, on a :
une ligne avec attname = 'C1_TEST' correspondant à la colonne de la table
une ligne avec attname = 'C1' correspondant à la colonne indexée (mais donc avec l'ancien nom de la colonne).
Conclusion :
il semble que le renommage d'une colonne ne renomme pas les composantes des index.
Dès lors l'index va-t-il toujours pouvoir être utilisé par PG ??
En regardant la documentation, on trouve dans les notes de version de la 7.2 (de mémoire, je ne retrouve plus la page) que ce renommage avait alors été implémenté.
Constatez vous la même chose ou avons nous loupé quelque chose ?
Merci de vos lumières, cordialement, Arnaud.
Pages : 1