Il me semble que sous Postgres, ou peut coder un peu ce qu'on veut en procédural, non ? Que ce soit en pl/pgsql ou en C même...
C'est assez vrai, il y a un certain nombre de languages qui permettent d'ecrire des triggers qui sont supportes de base par PG. Mais il n'y a pas le meme niveau d'integration que dans Oracle (Par exemple la possibilite de suivre pas a pas une transaction ou un export de donnees). Oracle a encore de l'avance a ce niveau, meme si PG commence a talonner de pres.
L'intégrité de la base n'est-il pas un point fort de PostgreSQL (surtout par rapport à MySQL) ? Foreign keys, transactions, etc...
PG s'en sort pas mal au niveau des controles d'integrite c'est vrai. Mais il y a a peu pres le meme ecart entre MySQL et PG qu'entre PG et DB2. DB2 possede (entre autre) des systemes d'indexs variables entre les donees consolidees et celles qui ne le sont pas, un systemes de rollback multibase (capable de remettre en etat precedent une base de donnees fille quand un truc foire sur une autre) et un systeme de shadow data(copie conforme de la base a l'etat n-1) qui permet d'eviter un maximum d'annerie (surtout lors des imports et exports de donnees exterieures). A ce niveau la PG ne joue pas du tout dans la meme cour que DB2 (Oracle non plus d'ailleurs)
Tu parles de "vocation objet", ça implique quoi ? Pour moi Postgres est une BDD relationnelle en premier lieu. Peux-tu préciser ce que tu entends par "bien se servir de Postgres" (ou "mal") ? Je suis preneur de choses à éviter et de trucs à savoir. Par "ménage", tu parles de vacuum ou d'autre chose ?
Ben je suis un peu comme toi je tatonne. Je n'ai pas la pretention d'etre un maitre es PostgreSQL, mais je me suis rendu compte que les fonctionalites objets permetaient de faire pas mal de chose pour limiter les effets du vacuum.
Notemment sur un flux de donnees non consolide (infos clients non valides, warning de prod non confirmes, infos non verifies etc...). J'ai un systemes de logs d'evenements qui rentre les donnees dans une base PG. Prob 90% des evennements sont des consequences d'un autre probleme plus general (ie si un routeur tombe on se doute bien qu'il va y avoir 200 machines qui ne vont plus repondre au ping, et on s'en fiche pas mal(ceci est un exemple tout commentaire du type "cretin d'admin il avait doubler les routes " n'est pas le bienvenu) ). On se retrouve donc avec 201 incidents dont un seul qui nous interresse. Au final dans l'historique des evenements on ne gardera que celui qui nous interresse et on fichera les 200 autres a la poubelle. => 200 fantomes pour le vacuum, bon apetit.
Autre solution, on cree un type "incident1" un peu comme on creerait une table temporaire, on externalise ses donnees vers un fichier texte. Au moment de consolider la base, on detourne les incidents qui arrivent vers un type "incident2", on recupere le sinfos qui nous interresse dans le type "incident1", on detruit le type "incident1" (attention pas de betise l'artiste travaille sans filet) et on shoote les fichier texte. Et qund le vacuum passe il trouve des donnees qui ne veulent rien dire pour lui (donc qu'il n'aura aucun remors a supprimer) et qui sont tres limitees (ce ne sont que des pointeurs vers une ligne de texte).
Ca ecconomise pas mal de temps.
Par menage j'entend les deux choses : Consolidation + vacuum.
On les perd pourquoi ?
Ben je sais pas pour toi , mais moi j'aime pas que ma base soit modifiee a tire larigo sans que je sois au courant. PostgreSQL a donc sur ma machine son comilo C dedie, son TCL dedie, son interpreteur phyton a lui. (Bon je sais je suis un peu maniaque, mais dans un environement de production ca vaut mieux).
De plus je prefere mettre en place de base un certains nombre de regles (vis a vis des timestamp et des formats de date en general) avant de me lancer dans la creation de BD. Bon je ne te cache pas qu'avec mes manie sil me faut pas loin de 10 heures pour monter un serveur PG dont je sois content, mais je pense que trois heures pour etre propre c'est un minimum.
[^] # Re: linuxfr.org dans une base postgresql ?
Posté par Jerome Herman . En réponse à la dépêche linuxfr.org dans une base postgresql ?. Évalué à 3.
C'est assez vrai, il y a un certain nombre de languages qui permettent d'ecrire des triggers qui sont supportes de base par PG. Mais il n'y a pas le meme niveau d'integration que dans Oracle (Par exemple la possibilite de suivre pas a pas une transaction ou un export de donnees). Oracle a encore de l'avance a ce niveau, meme si PG commence a talonner de pres.
L'intégrité de la base n'est-il pas un point fort de PostgreSQL (surtout par rapport à MySQL) ? Foreign keys, transactions, etc...
PG s'en sort pas mal au niveau des controles d'integrite c'est vrai. Mais il y a a peu pres le meme ecart entre MySQL et PG qu'entre PG et DB2. DB2 possede (entre autre) des systemes d'indexs variables entre les donees consolidees et celles qui ne le sont pas, un systemes de rollback multibase (capable de remettre en etat precedent une base de donnees fille quand un truc foire sur une autre) et un systeme de shadow data(copie conforme de la base a l'etat n-1) qui permet d'eviter un maximum d'annerie (surtout lors des imports et exports de donnees exterieures). A ce niveau la PG ne joue pas du tout dans la meme cour que DB2 (Oracle non plus d'ailleurs)
Tu parles de "vocation objet", ça implique quoi ? Pour moi Postgres est une BDD relationnelle en premier lieu. Peux-tu préciser ce que tu entends par "bien se servir de Postgres" (ou "mal") ? Je suis preneur de choses à éviter et de trucs à savoir. Par "ménage", tu parles de vacuum ou d'autre chose ?
Ben je suis un peu comme toi je tatonne. Je n'ai pas la pretention d'etre un maitre es PostgreSQL, mais je me suis rendu compte que les fonctionalites objets permetaient de faire pas mal de chose pour limiter les effets du vacuum.
Notemment sur un flux de donnees non consolide (infos clients non valides, warning de prod non confirmes, infos non verifies etc...). J'ai un systemes de logs d'evenements qui rentre les donnees dans une base PG. Prob 90% des evennements sont des consequences d'un autre probleme plus general (ie si un routeur tombe on se doute bien qu'il va y avoir 200 machines qui ne vont plus repondre au ping, et on s'en fiche pas mal(ceci est un exemple tout commentaire du type "cretin d'admin il avait doubler les routes " n'est pas le bienvenu) ). On se retrouve donc avec 201 incidents dont un seul qui nous interresse. Au final dans l'historique des evenements on ne gardera que celui qui nous interresse et on fichera les 200 autres a la poubelle. => 200 fantomes pour le vacuum, bon apetit.
Autre solution, on cree un type "incident1" un peu comme on creerait une table temporaire, on externalise ses donnees vers un fichier texte. Au moment de consolider la base, on detourne les incidents qui arrivent vers un type "incident2", on recupere le sinfos qui nous interresse dans le type "incident1", on detruit le type "incident1" (attention pas de betise l'artiste travaille sans filet) et on shoote les fichier texte. Et qund le vacuum passe il trouve des donnees qui ne veulent rien dire pour lui (donc qu'il n'aura aucun remors a supprimer) et qui sont tres limitees (ce ne sont que des pointeurs vers une ligne de texte).
Ca ecconomise pas mal de temps.
Par menage j'entend les deux choses : Consolidation + vacuum.
On les perd pourquoi ?
Ben je sais pas pour toi , mais moi j'aime pas que ma base soit modifiee a tire larigo sans que je sois au courant. PostgreSQL a donc sur ma machine son comilo C dedie, son TCL dedie, son interpreteur phyton a lui. (Bon je sais je suis un peu maniaque, mais dans un environement de production ca vaut mieux).
De plus je prefere mettre en place de base un certains nombre de regles (vis a vis des timestamp et des formats de date en general) avant de me lancer dans la creation de BD. Bon je ne te cache pas qu'avec mes manie sil me faut pas loin de 10 heures pour monter un serveur PG dont je sois content, mais je pense que trois heures pour etre propre c'est un minimum.
Kha