Bonjour à tous,
je vois dans les nombreuses nouveautés de SPIP 2.0
la possibilité d'accepter le PostgreSQL. Je suis
donc allé fouiner un peu sur le net pour essayer
de comprendre la différence, c'est plutôt costaud
et je n'y saisis goutte, apparemment les deux
systèmes ont leurs propres avantages ; concrètement,
dans quel(s) cas doit-on, peut-on recourir à une
base en PostgreSQL, dans quel(s) cas est-il préférable
de l'utiliser, bref, PostgreSQL, ça sert à quoi ? Merci
fsns
Salut,
Le dimanche 14 décembre 2008 à 05:44 +0000, fsns a écrit :
Bonjour à tous,
je vois dans les nombreuses nouveautés de SPIP 2.0
la possibilité d'accepter le PostgreSQL. Je suis
donc allé fouiner un peu sur le net pour essayer
de comprendre la différence, c'est plutôt costaud
et je n'y saisis goutte, apparemment les deux
systèmes ont leurs propres avantages ; concrètement,
dans quel(s) cas doit-on, peut-on recourir à une
base en PostgreSQL, dans quel(s) cas est-il préférable
de l'utiliser, bref, PostgreSQL, ça sert à quoi ? Merci
Hum, je ferai une réponse pas l'absurde. Si tu ne sais pas à quoi ça
sert c'est que ça ne te sert pas.
Si toutefois tu veux des détails, lit ci-dessous 
Pour essayer d'y répondre un peu tout de même, PostgreSQL est un système
de gestion de bases de données lui aussi libre. Il est prévu pour un tas
d'applications, pas forcément web, et permet un grand nombre de
fonctionnalités que ne permet pas MySQL, et inversement.
SPIP est prévu pour nativement fonctionner sur MySQL, qui est un
"standard" sur les nombreux hébergeurs "grands public". SPIP a été
adapté pour pouvoir se connecter à des serveurs PostreSQL et donc de ne
pas à avoir à y installer une instance MySQL à côté du PostgreSQL là où
ce dernier existait avant de se poser la question de l'intérêt de SPIP.
C'est ainsi par exemple que des applications nécessitant PostgreSQL
peuvent maintenant partager des tables de bases de données avec SPIP.
Espérant ne pas avoir trop noyé le poisson
A+
--
RSS Redirecting...
Logiciels Libres http://clx.asso.fr/
Hébergement http://lautre.net/
Concerts http://www.benevolat-grandmix.info/
jabber daffy@mailfr.com
Bonjour,
La réponse est correcte 
Si vous ne savez pas à quoi cela peut servir, vous n’êtes sans doute pas concernés.
Vous êtes potentiellement concernés - à l’inverse - si vous faites vos propres requêtes SQl, vos propres codes en php.
C’est à dire que déjà, vous n’utilisez pas que les boucles SPIP telles quelles, ou que vous les complétez par des requêtes personnalisées.
(En supposant que vous ne puissiez pas les réaliser avec la mouture de MySQL proposée… cas rare)
Un autre cas ou vous pouvez être concernés, est l’installation de SPIP chez un hébergeur, un intranet,… ou le choix de la base de donnée initiale est PostGresSQL.
Dans ce cas, vous n’êtes pas gênés , ni contraint par ce choix initial.
Et au lieu de supplier l’administrateur d’installer MySQL, vous utilisez tout simplement le PostGres installé.
Bon, donc une ouverture de SPIP, tout simplement à une autre base de donnée standard (et libre).
Ah, petit point de détail, si vous commencez à utiliser des requêtes qui ne s’exécutent que dans un environnement…vous figez votre évolution future…
Donc, testez votre code php sous les deux environnements.
Mais n’oubliez pas, si vous utilisez des DB différentes, d’externaliser les fonctions différentes, pour les rendre indépendantes de la cible.
Il faut bien distinguer ce qui relève de la norme et des extensions…
Exemple : Postgres et MySQL traitent differemment majuscules et minuscules.(Donc, attention aux conventions de nommage.), faire attention aux tables MySQL avec index en auto-increment, etc.
Donc, restez ‹ universels › et laissez de côté - si vous n’êtes pas spécialiste des bases de données - ces subtilités à d’autres.
Et, si vous interfacez directement une base de donnée, faites attention aux choix des uns et des autres…
Ah, n’oubliez pas tout de même, de tester les plugins que vous désirez utiliser sous la DB concernée
(je parle des plugins utilisant les acces BD, comme « acces restreint », ou autres…, qui attaquent directement certaines bases de données, voire les modifient…)
fsns a écrit :
DaffyDuke a écrit :
Hum, je ferai une réponse pas l’absurde. Si tu ne sais pas à quoi ça sert c’est que ça ne te sert pas.
Le point le plus important est que l'on peut désormais dans un site SPIP
faire des boucles sur des tables appartenant à bases de données externes,
par exemple un annuaire ou un catalogue, quel que soit le gestionnaire
de base de données sous lequel ces bases ont été développées.
-- Fil
Bonjour,
Le ‹ problème › de portabilité a été abordé - brièvement…
Celui-ci n’existe (à priori) que pour à ceux qui
Exemple :
Vous avez écrit un magnifique plugin avec un champ d’indexation en Auto-increment…
dommage !
donc, recherche Google et par exemple :
http://www.xach.com/aolserver/mysql-to-postgresql.html
http://www.commentcamarche.net/contents/postgresql/postgresintro.php3
http://archives.postgresql.org/pgsql-general/1999-01/msg00228.php
Bon, ce n’est qu’une approche…
La portabilité est un art difficile.
Il ne faut pas oublier que quel que soit le système de base de données, il ne respecte jamais la norme totalement.
Il n’y a donc aucune raison pour que deux DB aient les mêmes conventions. Ni qu’ils possèdent les mêmes outils.
Pour la plupart vous utilisez simplement les boucles natives de SPIP
Vous pouvez utiliser (toujours à priori) une base PostgresSQL de la même manière qu’une base MySQL.
Voire les deux en même temps…
Car ce sont les développeurs de SPIP qui se sont ‹ payés › le sale boulot de mise en ‹ conformité › de SPIP avec les deux DB.
Mais, en informatique, il vaut mieux vérifier trois fois, sachant que si tout marche correctement, c’est que deux erreurs se neutralisent
De toutes façons - on ne le répète jamais assez - on ne teste jamais une solution nouvelle sur un site de production !
amicalement
Jel
Le point le plus important est que l'on peut désormais dans un site SPIP
faire des boucles sur des tables appartenant à bases de données externes,
par exemple un annuaire ou un catalogue, quel que soit le gestionnaire
de base de données sous lequel ces bases ont été développées.
-- Fil
jel.spip a écrit :
Exemple :
Vous avez écrit un magnifique plugin avec un champ d'indexation en Auto-increment...
Oui, mais cependant, SPIP a plus d'un ressort dans son sac... Donc pour rebondir sur cette phrase, les gestionnaires PostGres et SQLite de SPIP arrivent à s'adapter aux écritures MySQL (vu que SPIP était uniquement codé pour lui au début).
Ainsi, si vous déclarez une table avec "autoincrement" sur la primary key à la façon de SPIP (comme dans /base/serial et /base/auxiliaires en utilisant les pipelines spécifiques SPIP 2 "declarer_tables_principales" et "declarer_tables_auxiliaires"), SPIP traduira le champ autoincrement pour qu'il soit pris en compte lorsqu'on utilise PG ou SQLite. Bref, SPIP s'adapte de la syntaxe mysql (dans une certaine mesure).
De la même manière, une déclaration de champ "ENUM" spécifique à Mysql sera tout de même fonctionnel sous PG ou SQLite. L'inverse par contre n'est pas valable (des déclarations spécifiques PG ne seront pas comprises par les autres)
Dans tous les cas, lorsque SPIP est simplement utilisé pour "afficher" les contenus de tables PG ou SQLite, aucune déclaration de la structure des tables n'est nécessaire et utile, SPIP se débrouillant très bien tout seul pour récupérer les informations qui lui sont nécessaires sur les tables qu'il à a afficher.
Même lorsqu'on se sert de SPIP pour écrire du contenu dans les tables, avec les fonctions sql_* , il n'est pas indispensable de déclarer la structure de la table en question si elle existe déjà.
Par contre, les déclarations des structures de tables sont indispensables dès lors que vous créez un plugin qui doit créer justement les tables dont il a besoin pour fonctionner, car c'est à partir d'elle que SPIP construit la requête de création ou de mises à jour des tables.
--
MM.