Discussion :

[Community Management]

Le PostgreSQL Global Development Group annonce la publication de PostgreSQL 9.3, la dernière version du système de gestion de bases de données relationnelles open source le plus évolué.

Cette version étend la fiabilité, la disponibilité et la capacité de PostgreSQL à s'interfacer avec d'autres bases de données comme Oracle ou les bases NoSQL.

Les utilisateurs rapportent déjà des développements rendus possibles par cette version.

« PostgreSQL 9.3 fournit des fonctionnalités qu'en tant que développeur d'applications je peux utiliser immédiatement : des fonctionnalités JSON améliorées, l'indexation d'expressions rationnelles, et la facilité à fédérer des bases de données grâce aux gestionnaires de données externes (« Foreign Data Wrapper », en anglais) de PostgreSQL. Je me demande réellement comment je pouvais mener à bien mes projets avant cette version », déclare Jonathan S. Katz, CTO de VenueBook.


Accès en écriture aux données externes

La version 9.3 de PostgreSQL permet l'écriture au travers des gestionnaires de données externes (« Foreign Data Wrappers », en anglais). Cela permet les échanges bidirectionnels entre plusieurs systèmes. Les environnements informatiques d'aujourd'hui intègrent plusieurs bases de données et des sources de données semi-structurées. PostgreSQL permet de les intégrer dans un ensemble cohérent. L'équipe a également développé postgres_fdw, pilote hautement performant de fédération PostgreSQL-PostgreSQL en lecture/écriture.

« Les gestionnaires de données externes modifiables nous permettent de connecter et tester très facilement différentes alternatives. Divers besoins sont adressés rapidement et le prototypage devient intelligent », explique Lee Holloway, co-fondateur et directeur de l'ingéniérie chez CloudFlare. « Il est intéressant d'assembler de nouveaux moteurs de stockages de données (dont les nôtres, écrits en Go), de les mélanger et de les regarder lire, écrire, voire interagir entre eux. »


Fiabilité et disponibilité renforcées

« PostgreSQL a toujours eu ma préférence pour sa stabilité, sa robustesse, ses garanties de cohérence et de durabilité des données, son respect des propriétés ACID et de la norme SQL » affirme Pascal Bouchareine, directeur Recherche et Développement chez Gandi.net. « Je suis particulièrement impatient d'en apprendre plus sur le mécanisme de bascule rapide annoncé en 9.3. »

Cette nouvelle version inclut de nouvelles fonctionnalités qui étendent et améliorent encore la fiabilité et la disponibilité de PostgreSQL :

• sommes de contrôle sur les pages de données : aide les administrateurs à détecter rapidement tout disque ou composant matériel défectueux qui corrompt les données ;
• bascule rapide : bascule en moins d'une seconde entre le maître et le réplicat, offrant une disponibilité dite « carrier-grade » ;
• resynchronisation par streaming simple : reconfiguration plus simple, plus rapide des réplicats en cascade après bascule.

Fonctionnalités orientées développeurs

Comme toute nouvelle version, PostgreSQL 9.3 propose de nombreuses fonctionnalités facilitant le travail avec PostgreSQL. Cela le rend plus flexible et plus agréable pour les développeurs, les administrateurs et les architectes.
Parmi ces fonctionnalités, citons :

• des méthodes additionnelles de constructeur et extracteur JSON ;
• les vues matérialisées et les vues inscriptibles ;
• la possibilité de paralléliser pg_dump pour accélérer les sauvegardes des bases volumineuses ;
• les LATERAL JOIN.

De plus, avec PostgreSQL 9.3, la possibilité de définir ses propres processus autonomes intégrés (« Background Workers », en anglais) permet aux développeurs d'écrire des gestionnaires de tâches, des gestionnaires de requêtes, des traitements parallèles, des outils de « queueing » ou toute autre application permettant d'utiliser PostgreSQL comme séquenceur de tâches.
Un exemple concret est Mongres, un processus autonome intégré qui accepte les requêtes MongoDB, les interprète et les transmet à PostgreSQL.

Détails des fonctionnalités
Pour en savoir plus sur les fonctionnalités décrites ci-dessus et d'autres fonctionnalités de cette nouvelle mouture :

• Notes de version
• Les nouveautés

Téléchargement
Vous pouvez télécharger la dernière version de PostgreSQL depuis le site du projet.

Sources
http://www.postgresql.org/about/press/presskit93/fr

Et vous ?
Que pensez-vous de cette nouvelle mouture du SGBD libre ?
Que pensez-vous des nouveautés de cette version ?
Allez-vous l'adopter ?

[alassanediakite]

Salut
Deepin Pourquoi ne pas ouvrir un sondage où nous pouvons exprimer nos attente sur les futurs versions de PostgreSQL? Cela permet de ressortir des fonctionnalités cachées, des difficultés et leurs contournements.
La fonctionnalité background worker semble être donnée uniquement aux supers experts, vue les exemples de mise en œuvre que j'ai trouvé sur le web.
Peut on avoir une mise en œuvre simple (sinon une explication assez complète) de la part de qui que ce soit.
@+

[SQLpro]

Mine de rien il y a quelques avancées majeures importantes :
1) la somme de contrôle sur les pages. Avant il était impossible de voir si les données des bases étaient corrompues ou pas. Seule un outil système permettait de faire, cela, mais supposait de fermer la base à toute écriture le temps de procéder à la chose !!! Impensable pour des bases 24h/24...
2) les foreign_data_wraper et notamment pour PG qui permettent désormais de faire des transactions en écrivant sur plusieurs bases de plusieurs servuers... Enfin, je suppose !
3) les vues matérialisées.... Là je demande à voir et tester, car la solution de partitionnement ignoble que PG nous a donnée s'est vite avérée inexploitable. Espérons que les vues matérialisées sont simples et performantes....
4) les jointures LATERAL, qui comme je l'ai montré dans ce benchmark : http://blog.developpez.com/sqlpro/p9...alles_en_sql_1 pénalisait PostGreSQL du fait de son incapacité à permettre ce stype de requêtes (que Microsoft SQL Server nomme APPLY {CROSS ou OUTER} )

C'est dommage qu'il n'y ait pas relativement au point 1 un outil de réparation des pages endommagées, comme c'est le cas de SQL Server (il est même automatique et transparent en cas de mirroring...)

De même j'aurais bien vu des avancées qui tardent à venir sur la haute dispo notamment en terme de réindexation "online" ou de DDL "online"...

mais bref, c'est déjà pas si mal !!!

A +

[Chauve souris]

Je vais faire la fine bouche mais PostgreSQL semble entrer dans ce phénomène de privatisation comme PGP, MySQL et autres. En ce cas c'est EnterpriseDB. Il y a des PostgreSQL Server payants et, subsiste encore une version "community", comme avec MySQL. Mais pour combien de temps ?

Autrement dit est-ce la peine d'investir du jus de cervelle pour se retrouver à terme avec un système payant où, concurrence oblige, PostgreSQL risque de ne pas être le mieux placé.

Au moins avec Microsoft SQL Sever c'est clair : il y a la version gratuite, bridée certes mais qui restera gratuite, et la version payante (la Rolls des SGBD).

PS : gag : voulant installer pgAdmin III sur une machine cliente pour me connecter au serveur, je ne trouve que la version 1.16 incompatible. Impossible de trouver la version 1.18 seule chez EnterpriseDB. Avec peine je trouve une beta1.

[punkoff]

Ah le lobbying... vous auriez pu au moins faire ceci d'une façon une peut plus subtile / objective.


Sinon concernant votre gag je ne comprend pas bien vu que pgAdmin est un outil externe non développé par l'équipe postgeSql ...?

[SQLpro]

Je vais faire la fine bouche mais PostgreSQL semble entrer dans ce phénomène de privatisation comme PGP, MySQL et autres. En ce cas c'est EnterpriseDB. Il y a des PostgreSQL Server payants et, subsiste encore une version "community", comme avec MySQL. Mais pour combien de temps ?

Vous oubliez une chose... MySQL est à l'origine un produit privé avec du code privatisable et qui a été privatisé, donc le tronc de code est à l'origine copyrighté !
Ce n'est pas le cas de PostGreSQL qui est basé sur du code communautaire donc totalement libre. Cela n'empêchera pas des fork privés, mais le tronc reste ouvert et libre...

C'est une différence majeure !

Et pourtant dieu sait si j'ai été vilipendé pour mes positions soit disant "hayathollique" au sujet des problèmes du droit du libre...

A +

[estofilo]

En ce cas c'est EnterpriseDB. Il y a des PostgreSQL Server payants et, subsiste encore une version "community", comme avec MySQL.

Depuis le début il n'y a qu'une seule version de référence de PostgreSQL, qui est celle produite par le groupe de volontaires. Enfin les volontaires en question sont salariés par diverses entreprises mais aucune qui prédomine.
Ce qui contraste avec MySQL, qui a toujours été contrôlé par une entreprise, aujourd'hui Oracle par rachats successifs.

Les déclinaisons commerciales fermées de PostgreSQL occupent des niches par rapport à la version communautaire.
Il se trouve qu'EnterpriseDB a un positionnement marketing consistant à se présenter comme une version "Entreprise" du "produit", mais c'est du marketing.
La réalité est que si EnterpriseDB s'arrêtait demain, ça ne changerait pas grand chose à l'avenir de PostgreSQL.

Ce qui peut induire en erreur, ce sont les packages pré-compilés parce que le groupe officiel de développeurs ne les fait pas lui-même.
Pour Windows, la gestion du packaging a été laissée à EntrepriseDB avec son installeur "tout intégré" StackBuilder incluant PgAdmin et d'autres choses. Le résultat est que ça manque de clarté par rapport à des logiciels mono-fournisseur.

Pareil pour MacOS X où PostgreSQL est packagé indépendamment par plusieurs fournisseurs tiers, dont EntrepriseDB.

Et pour Linux c'est noyé dans les milliers de packages disponibles dans les distributions.

[alassanediakite]

Salut
Chauve souris pour les critiques. Par cela nous pouvons détruire les fausses accusations.
Pour gag.
@+

[blemjid]

Voici pour chauve souris:
http://www.postgresql.org/ftp/pgadmi...e/v1.18.0/src/

Bien à vous

[Shirraz]

Je ne comprends pas bien l'avancée des vues matérialisées, hormis qu'elles soient sauvegardées physiquement. Les règles ne sont plus utilisables, et bien que la doc parle de la possibilité d'ajouter des index sur une vue matérialisée, pgAdmin III (1.18) n'en offre pas la possibilité... Si je la crée manuellement, la requête fonctionne, mais la vue ne semble pas affectée...

[punkoff]

Je ne comprends pas bien l'avancée des vues matérialisées, hormis qu'elles soient sauvegardées physiquement. Les règles ne sont plus utilisables, et bien que la doc parle de la possibilité d'ajouter des index sur une vue matérialisée, pgAdmin III (1.18) n'en offre pas la possibilité... Si je la crée manuellement, la requête fonctionne, mais la vue ne semble pas affectée...

Ca permet de stocker le résultat de requete complexe. (pensez agrégation, recurssion etc)

Les données stockées ne sont pas rafraichi automatiquement, du coup rajouter des règles sur ce type de vue n'a pas de sens.

[SQLpro]

Effectivement PostgreSQL a entrepris de faire des vues matérialisées à la Oracle, qui ne sont pas synchrones avec les données, alors que c'est la cas des vues indexées de SQL Server. Autrement dit quelque chose qui rappelle plus les tables temporaires que de vrais vues indexées... Dommage !

A +

[Shirraz]

Ca permet de stocker le résultat de requete complexe. (pensez agrégation, recurssion etc)

Les données stockées ne sont pas rafraichi automatiquement, du coup rajouter des règles sur ce type de vue n'a pas de sens.

Oui, mais je n'aurai pas trouvé illogique que l'on soit contraint de rafraîchir manuellement la vue après une requête l'ayant modifier, où même que ce soit automatique...

Du coup si j'ai besoin d'une vue regroupant des tables régulièrement modifiées (ce qui me semble un peu inévitable dans la mesure où tout est relationnel derrière), il faut une vue normale sur lesquelles faire des requêtes update / delete mettant manuellement à jour une vue matérialisée qui servira uniquement aux select pour profiter de sa persistence...

Comme je disais, à la limite je ferai avec (sûrement même "j'apprendrai à mieux faire" tout court), mais ce qui me perturbe vraiment c'est que la doc parle bien d'indexation, de contraintes ou de règles sur les vues matérialisées. La version de PgAdmin supportant la 9.3 offre également la possibilité de créer des règles et triggers (mais pas d'index), jusqu'au moment ou "non, pas possible sur les vues matérialisées). Bref, d'où la déception / incompréhension... ou la dépression car sinon c'est que je suis juste taré.

http://www.postgresql.org/docs/9.3/s...lizedview.html

All parameters supported for CREATE TABLE are also supported for CREATE MATERIALIZED VIEW with the exception of OIDS.

Ici il est bien dit que les vues matérialisées utilisent également les règles, à la seule différence qu'il faudra raffraîchir manuellement
http://www.postgresql.org/docs/9.3/s...izedviews.html

Materialized views in PostgreSQL use the rule system like views do, but persist the results in a table-like form. The main differences between:
CREATE MATERIALIZED VIEW mymatview AS SELECT * FROM mytab;

and:
CREATE TABLE mymatview AS SELECT * FROM mytab;

are that the materialized view cannot subsequently be directly updated and that the query used to create the materialized view is stored in exactly the same way that a view's query is stored, so that fresh data can be generated for the materialized view with:
REFRESH MATERIALIZED VIEW mymatview;

Après par "pas directement" je sais pas s'ils entendent "impossible" ou "indirectement via les règles". Mais là, ils créent un index dessus, je rêve pas ??

CREATE MATERIALIZED VIEW wrd AS SELECT * FROM words;
CREATE UNIQUE INDEX wrd_word ON wrd (word);

[punkoff]

bonjour,

Le but d'une vue matérialisée n'est pas d'avoir des données fraiche.
Mais d'avoir des données consolidées à un instant T.




Sinon pour vos questions, la partie que vous quottez est incomplète :

CREATE MATERIALIZED VIEW is similar to CREATE TABLE AS, except that it also ...

CREATE TABLE AS est différent de CREATE TABLE.

CREATE TABLE AS ne reprend pas les contraintes, ni les indexs.


Je ne vois pas non plus dans la doc la partie "création de contraintes" sur une materialized view (qui n'aurai pas de sens d'ailleurs).

Les actions possibles en ALTER sont décrites ici : http://www.postgresql.org/docs/9.3/s...lizedview.html

Ici il est bien dit que les vues matérialisées utilisent également les règles, à la seule différence qu'il faudra raffraîchir manuellement

Jje penses que vous avez mal interprété ce qui est écrit :

the rule is only used for populating the materialized view

Il n'est pas écrit que l'on peut mettre des rule sur update / delete / insert.