Re[2]: [spip-dev] SPIP multi bases ...

Nicolas_Hoizey1 · Novembre 5, 2002, 1:27

Autant éviter les trolls, donc d'accord

Oui, l'idée est d'avancer et de ne pas polluer cette liste ...

Il faudrait faire le point de toutes les requètes sql utilisées par
SPIP.

Voir à la fin de ce message, liste établie par Fred Renaudin en juin
sur une 1.4 beta.

En fonction des SGBD visés, la syntaxe peut être différente, ou les
fonctionnalités (procédures stockées par exemple). C'est un point à
prendre en compte.

Je ne suis pas sûr que l'on ait besoin de procédures stockées,
l'essentiel des traitements fonctionnels devant tant que possible
rester dans le code PHP de SPIP pour qu'il soit présent une seule
fois.

On dirait une approche modules ;-D

Bof, pour moi les modules au sens où tu sembles les entendre (modules
fonctionnels, à priori) peuvent reposer aussi sur cette méthode, mais
c'est surtout la base pour une approche de modularité technique, un
type de framework technique.

Je pense personnellement qu'il faut dès maintenant se fixer une
liste de SGBD à intégrer.

C'est simple, les discussions que nous avons eu jusqu'à présent
semblait rendre PostgreSQL intéressant pour une personne, et Oracle
pour 4 ...

Après ça, faire en sorte que les requètes soient admises par tous.
C'est le rôle des librairies.

Les librairies doivent servir uniquement aux opérations de base
d'accès aux données, pas à la logique fonctionnelle de l'appli.

Voir également ce que l'on peut faire de "spécifique" à tel ou tel
SGBD (Proc stockée encore) et surtout tracer les modifs à faire dans
le code SPIP, notemment à l'install.

cf remarques précédentes.

-Nicolas

PS: liste des requêtes de SPIP

---------8<--------------------------------------------------
Partie front-office

Spip_pass.php3 :

Lg 33-34 : SELECT
Lg 37 : NUM_ROWS
Lg 38 : FETCH_ARRAY
Lg 58 : INSERT

Spip_image.php3 :

Lg 222-227 :SELECT
Lg 228 :FETCH_ARRAY
Lg 240 :UPDATE
Lg 245 :INSERT + AUTO-INCREMENT
Lg 247 :INSERT_ID
Lg 250 :INSERT
Lg 289 :INSERT + AUTO-INCREMENT
Lg 291 :INSERT_ID
Lg 292 :UPDATE
Lg 317 :UPDATE
Lg 322 :UPDATE
Lg 328 :UPDATE
Lg 364 :SELECT + FETCH_ARRAY
Lg 417 :SELECT
Lg 421-423 :UPDATE + DELETE

Inc-url-standard.php3 :

Lg 46-48 :SELECT + FETCH_ARRAY

Inc-url-html.php3 :

Lg 46-48 :SELECT + FETCH_ARRAY

Inc-stats.php3 :

Lg 16 :SELECT
Lg 19 :FETCH_ARRAY
Lg 27-30 :UPDATE

Inc-public.php3 :

Lg 89 :SELECT
Lg 91 :FETCH_ARRAY
Lg 224 :SELECT + INTERVAL
Lg 227 :FETCH_ARRAY
Lg 232 :DELETE

Inc-forum.php3 :

Lg 27 :SELECT
Lg 29 :FETCH_OBJECT
Lg 86 :SELECT
Lg 88 :DETCH_ARRAY
Lg 161-171 :SELECT + FETCH_OBJECT
Lg 182 :INSERT+NOW
Lg 185 :INSERT_ID
Lg 188-192 :SELECT + FETCH_ARRAY
Lg 214 :SELECT + AS + GROUP BY
Lg 216-217 :NUM_ROWS + FETCH_ARRAY
Lg 310 :SELECT + FETCH_ARRAY
Lg 317 :SELECT + NUM_ROWS
Lg 329 :FETCH_ARRAY
Lg 428 :SELECT
Lg 431 :FETCH_ARRAY
Lg 438 :DELETE
Lg 458 :DELETE
Lg 470 :INSERT
Lg 478 :UPDATE + NOW
Lg 491 :SELECT + FETCH_ARRAY
Lg 498 :SELECT + FETCH_ARRAY
Lg 538 :UPDATE
Lg 569 :SELECT + FETCH_ARRAY

Spip-cache.php3 :

Lg 15 :DELETE

Inc-formulaires.php3 :

Lg 13 :SELECT
Lg 15 :NUM_ROWS
Lg 31-33 :SELECT + NUM_ROWS
Lg 54 :SELECT + NUM_ROWS + FETCH_ARRAY
Lg 69 :SELECT + FETCH_ARRAY
Lg 83 :SELECT + NUM_ROWS
Lg 93 :SELECT + NUM_ROWS
Lg 105 :UPDATE
Lg 118 :SELECT + FETCH_ARRAY
Lg 142 :SELECT + NUM_ROWS
Lg 169 :SELECT + NUM_ROWS
Lg 183 :SELECT + FETCH_ARRAY
Lg 215 :INSERT + NOW
Lg 227 :SELECT + FETCH_ARRAY
Lg 289 :SELECT + NUM_ROWS + FETCH_ARRAY
Lg 305 :DELETE
Lg 322 :INSERT
Lg 392 :INSERT + NOW

Inc-cache.php3 :

Lg 122 :DELETE

Inc-calcul.php3 :

Lg 79 :SELECT + FETCH_ARRAY
Lg 104 :SELECT + FETCH_ARRAY
Lg 120 :SELECT + FETCH_OBJECT
Lg 166 :SELECT + FETCH_ARRAY
Lg 218 :SELECT + LEFT JOIN + FETCH_ARRAY
Lg 335 :SELECT + FETCH_ARRAY
Lg 397-415 :SELECT + FETCH_ARRAY

Inc-calcul-quel.php3 :

Toute la page

BACKOFFICE

Statistiques_tous.php3 :

Lg 42 :SELECT + MAX + FETCH_ARRAY
Lg 50 :SELECT + LIMIT

Statiqtiques_recents.php3 :

Lg 43 :SELECT + MAX + FETCH_ARRAY
Lg 51 :SELECT + DATE_SUB + LIMIT

Statistiques.php3 :

Lg 51 :SELECT + FETCH_ARRAY
Lg 58 :SELECT + SUM + FETCH_ARRAY
Lg 82 :SELECT + FETCH_ARRAY
Lg 137 :SELECT + COUNT + FETCH_ARRAY
Lg 143 :SELECT + COUNT + FETCH_ARRAY
Lg 147 :SELECT + COUNT + FETCH_ARRAY
Lg 160 :SELECT + FETCH_ARRAY

Sites-tous.php3 :

Lg 7 :DELETE
Lg 26-32 :SELECT
Lg 45 :SELECT
Lg 48 :SELECT

Sites-edit.php3 :

Lg 18 :SELECT + LIMIT + FETCH_ARRAY
Lg 35 :SELECT + FETCH_ARRAY
Lg 66 :SELECT + FETCH_ARRAY
Lg 172 :SELECT + FETCH_ARRAY

Sites.php3 :

Lg 77 :DELETE + DATE
Lg 80 :INSERT + NOW + INSERT_ID
Lg 86 :INSERT + FETCH_ARRAY
Lg 112 :UPDATE
Lg 132 :UPDATE
Lg 136 :UPDATE + NOW
Lg 156 :UPDATE
Lg 182 :UPDATE + DATE
Lg 200 :SELECT + FETCH_ARRAY
Lg 415 :SELECT
Lg 443 :SELECT

Rubriques-edit.php3 :

Lg 8 :INSERT + INSERT_ID
Lg 31 :SELECT + FETCH_ARRAY
Lg 57 :SELECT + FETCH_ARRAY
Lg 76 :SELECT + FETCH_ARRAY
Lg 147 :SELECT + COUNT + FETCH_ARRAY

Recherche.php3 :

Lg 18 :SELECT + LIKE + LIMIT

Optimiser.php3 :

Lg 17 :SELECT + FETCH_ARRAY
Lg 24-30 :DELETE + DATE
Lg 39 :SELECT + FETCH_ARRAY
Lg 46-50 :DELETE
Lg 59 :SELECT + FETCH_ARRAY
Lg 66 :DELETE
Lg 76 :DELETE + DATE
Lg 79 :SELECT + FETCH_ARRAY
Lg 86 :DELETE
Lg 95 :SELECT + FETCH_ARRAY
Lg 102-106 :DELETE
Lg 110 :SELECT + DATE + FETCH_ARRAY
Lg 115 :SELECT + NUM_ROWS
Lg 118 :DELETE
Lg 128 :SELECT + FETCH_ARRAY
Lg 135 :DELETE
Lg 138 :DELETE + DATE
Lg 149 :SELECT + FETCH_ARRAY
Lg 154 :SELECT + FETCH_ARRAY
Lg 162-164 :DELETE
Lg 173 :DELETE + DATE
Lg 176 :SELECT + FETCH_ARRAY
Lg 183 :DELETE
Lg 191 :OPTIMIZE

Naviguer.php3 :

Lg 16 :SELECT + FETCH_ARRAY
Lg 54 :SELECT + NUM_ROWS + FETCH_ARRAY
Lg 80 :SELECT + COUNT + FETCH_ARRAY
Lg 96 :UPDATE
Lg 109 :SELECT + FETCH_ARRAY
Lg 190 :SELECT + LIMIT + NUM_ROWS
Lg 338-fin :SELECT + DATE

Mots-types.php3 :

Lg 9 :SELECT + INSERT_ID
Lg 15 :SELECT + FETCH_ARRAY

Mots-tous.php3 :

Lg 6 :DELETE
Lg 11 :SELECT + FETCH_ARRAY
Lg 22-41 :SELECT + COUNT + FIND_IN_SET + FETCH_ROWS
Lg 57 :UPDATE
Lg 60 :UPDATE
Lg 69 :DELETE
Lg 130 -167 :SELECT + COUNT + FIND_IN_SET + FETCH_ARRAY
Lg 177 :SELECT + FETCH_ARRAY
Lg 236 :SELECT + NUM_ROWS + FETCH_ARRAY
Lg 252 :SELECT + COUNT + FETCH_ARRAY

Mots-edit.php3 :

Lg 23-31 :INSERT + INSERT_ID + DELETE
Lg 40 :SELECT + FETCH_ARRAY
Lg 45 :UPDATE
Lg 67 :SELECT + FETCH_ARRAY
Lg 191-205 :SELECT + FIND_IN_SET + LIMIT
Lg 218 :SELECT + FETCH_ARRAY
Lg 251 :SELECT + FETCH_ARRAY

Jour 2 -> seulement les requetes plus complexes

Message_edit.php3 :

Lg 13 :DELETE + DATE
Lg 19 :INSERT + INSRET_ID
Lg 24 :INSERT + HEURE

Message.php3 :

Lg 8 :SELECT + COUNT
Lg 85 :UPDATE + DATE
Lg 90 :DELETE + NOW
Lg 564 :SELECT + LIMIT

Install.php3 :

Lg 68 :SELECT + COUNT + NUM_ROWS
Lg 146 :CREATE_DB + SELECT_DB + NUM_ROWS
Lg 200 :LIST_DBS
Lg 210 :DB_NAME
Lg 260 :ERRNO

Index.php3 :

Lg 179 :NUM_ROWS
Lg 295 :SELECT + DATE
Lg 319-337 :SELECT + LIMIT + NUM_ROWS

Inc-site.php3 :

Lg 99 :UPDATE + NOW
Lg 146 :INSERT + DATE + INSERT_ID
Lg 191 :INSERT_ID
Lg 198 :UPDATE + NOW
Lg 230 :NUM_ROWS
Lg 298 :FETCH_ROW
Lg 338 :NUM_ROWS
Lg 451-fin :DATE

Inc-presentation.php3 :

Lg 37 :SELECT + DATE
Lg 268- 309 :LIMIT
Lg 330-538 :NUM_ROWS + FREE_RESULT
Lg 570 :NUM_ROWS
Lg 677 :FREE_RESULT
Lg 685 :DATE
Lg 1289 :NUM_ROWS
Lg 1297 :DATE + NUM_ROWS
Lg 1426 :DATE + INTERVAL + NUM_ROWS
Inc_mots.php3 :

Lg 100-103 :NUM_ROWS
Lg 208 :NUM_ROWS
Lg 222 :NUM_ROWS
Lg 352 : !=

Inc-mail.php3 :

Lg 162 :DATE + NUM_ROWS + FREE_RESULT
Lg 177 :DATE + NUM_ROWS
Lg 205 :DATE + NUM_ROWS

Inc-index.php3 :

Lg 63 :DELAYED IGNORE
Lg 159 :DATE
Lg 217 :DATE

Inc_import.php3 :

Lg 198 :REPLACE
Lg 281 :REPLACE
Lg 430-452 :DATE

Inc-export.php3 :

Lg 60 :NUM_ROWS
Lg 62 :LIMIT
Lg 77 :NUM_ROWS
Lg 72 :LIMIT
Lg 99 :NUM_FIELDS + FIELD_NAME
Lg 115-169 :FREE_RESULT
Lg 177 :FREE_RESULT

Inc-connect.php3 :

Tout :CONNECT + SELECT_DB + NUM_ROWS

Inc-base.php3 :

Tout :CREATE TABLE
                :INSERT IGNORE
                :ALTER TABLE
                :DISTINCT
                :DROP TABLE
                :LENGTH

inc-auth.php3 :

lg 138 :NUM_ROWS
lg 168 :DATE
lg 176 :NUM_ROWS

inc.php3 :

lg 190-209 :LIMIT
lg 229 :DATE
lg 321-341 :MAX + GROUP BY
lg 371 :DISTINCT + DATE
lg 392 :DISTINCT

forum-admin.php3 :

lg 24 :DATE
lg 90 :LIMIT

forum.php3 :

lg 23 :DATE
lg 91 :DATE

export.php3 :

lg 19&39 :FREE_RESULT
lg 71 :DISTICT

delete-all.php3 :

DROP TABLE

Controle-petition.php3 :

Lg 35 :DATE
Lg 73 :NUM_ROWS
Lg 169 :DATE

Controle-forum.php3 :

Lg 176 :NUM_ROWS
Lg 290 :DATE
Lg 306 :DATE + LIMIT

Calendrier.php3 :

Lg 60-85 :DATE

Breves-voir.php3 :

Lg 77 :DATE

Breves-edit.php3 :

Lg 11&14 :DATE + INSERT_ID

Breves.php3 :

Lg 32 :DATE + NUM_ROWS
Lg 52 :FIND IN SET + LIMIT
Lg 57 :NUM_ROWS
Lg 150 :DATE

Auteurs-edit.php3 :

Lg 149 :FIND IN SET + LIMIT + DATE

Auteurs.php3 :

Lg 244 :FIND IN SET
Lg 254 :FIND IN SET

Auteur-info.php3 :

Lg 52 :INSERT_ID

Auteur_connexion.php3 :

Lg 79 :NUM_ROWS
Lg 299 &320 :NUM_ROWS

Articles_tous.php3 :

Lg 173 :FREE_RESULT

Articles_pages.php3 :

Lg 13 :LIMIT + NUM_ROWS

Articles-forum.php3 :

Lg 72 :DATE

Articles-edit.php3 :

Lg 23&28 :DATE + INSERT_ID
Lg 64&76 :NUM_ROWS

Articles.php3 :

Lg 42 :NUM_ROWS
Lg 78 :DATE
Lg 101 :DATE
Lg 118 :DATE
Lg 278 :DATE + NUM_ROWS
Lg 433 :REPLACE
Lg 445 :NUM_ROWS
Lg 550 :LIMIT
Lg 950 :NUM_ROWS
Lg 1054&1061:NUM_ROWS
Lg 1311 :DATE + LIMIT

Messagerie.php3 :

Lg 50 :DATE
Lg 64 :NUM_ROWS
Lg 146 :FREE_RESULT
Lg 156-fin :DATE
---------8<--------------------------------------------------

Herve_LEFEBVRE · Novembre 5, 2002, 5:23

En réponse à Nicolas Hoizey <nhoizey@php.net>:

> En fonction des SGBD visés, la syntaxe peut être différente, ou les
> fonctionnalités (procédures stockées par exemple). C'est un point à
> prendre en compte.

Je ne suis pas sûr que l'on ait besoin de procédures stockées,
l'essentiel des traitements fonctionnels devant tant que possible
rester dans le code PHP de SPIP pour qu'il soit présent une seule
fois.

Si tu pars comme ça, c'est mal parti...

Peu importe la façon dont est implémentée la couche d'accès aux données, elle
doit être transparente. Que ce soit des requêtes, des appels de proc
stock ou quoique ce soit d'autre, rien ne doit être redhibitoire.

Par exemple ça me ferait mal d'avoir une BD corrompue sous pgSQL ou Oracle. Je
compte bien faire du BEGIN TRANSACTION/COMMIT. Sinon, quel intérêt ?

Autre chose, l'idée du getArticle(), getBreve() etc. est mauvaise. Je peux le
dire puisque lidée était plus oumoins de moi

Elle est mauvaise parce que les reqêtes, y compris les noms de tables, sont
très souvent générés dynamiquement dans le code. Et il faudrait éviter du
code du genre :

switch ($boucle)
{
   case "ARTICLES":
      getArticle(...);
      break;
   case "BREVES":
      getBreve(...);
}

Il vaudrait mieux quelquechose du genre :

getObject("ARTICLES",$criteres,$tri ...)

Comme ça au moins le SWITCH/CASE sera factorisé dans la couche d'abstraction.

Ne pas négliger non plus les aspects import/export de base et creation/upgrade
à l'install.

Nicolas_Hoizey1 · Novembre 5, 2002, 5:29

Si tu pars comme ça, c'est mal parti...

On est là pour discuter, pas pour descendre l'autre dès qu'il propose
quelque chose, même si ça parait con, donc merci de modérer un peu tes
propos ...

Peu importe la façon dont est implémentée la couche d'accès aux
données, elle doit être transparente. Que ce soit des requêtes, des
appels de proc stock ou quoique ce soit d'autre, rien ne doit être
redhibitoire.

En quoi une proc stock va apporter un plus pour une bête sélection de
données par rapport à un select classique ?

Par exemple ça me ferait mal d'avoir une BD corrompue sous pgSQL ou
Oracle. Je compte bien faire du BEGIN TRANSACTION/COMMIT. Sinon,
quel intérêt ?

Quel rapport avec des proc stocks ???

Autre chose, l'idée du getArticle(), getBreve() etc. est mauvaise.
Je peux le dire puisque lidée était plus oumoins de moi

OK.

Elle est mauvaise parce que les reqêtes, y compris les noms de
tables, sont très souvent générés dynamiquement dans le code. Et il
faudrait éviter du code du genre :

switch ($boucle)
{
   case "ARTICLES":
      getArticle(...);
      break;
   case "BREVES":
      getBreve(...);
}

En effet.

Il vaudrait mieux quelquechose du genre :

getObject("ARTICLES",$criteres,$tri ...)

Comme ça au moins le SWITCH/CASE sera factorisé dans la couche
d'abstraction.

Tu veux dire qu'il va falloir reproduire le switch dans toutes les
libs, plutôt qu'une fois dans le code principal, là, ou je suis
complètement à côté de la plaque ?

Ne pas négliger non plus les aspects import/export de base et
creation/upgrade à l'install.

Ne serait-ce qu'à cause des différences de fonctionnalités et de
gestion des droits selon les différents SGBD, je ne suis de toute
façon pas sûr que ces fonctionnalités très sympa soient portables
totalement. Bien entendu, il faut les conserver sur les SGBD où c'est
possible, mais cela sort du cadre de l'abstraction, puisque ce n'est
pas de l'utilisation quotidienne de SPIP.

-Nicolas

Herve_LEFEBVRE · Novembre 5, 2002, 6:03

> Si tu pars comme ça, c'est mal parti...

On est là pour discuter, pas pour descendre l'autre dès qu'il propose
quelque chose, même si ça parait con, donc merci de modérer un peu tes
propos ...

Désolé, la prochaine fois, au lieu d'écrire mon mail en 5 minutes, je le
ferait corriger par 2 ou 3 diplomés de science-po, un diplomate, un avocat et
un philologue pour m'assurer qu'il n'y a pas de virgule mal placée laissant
la possibilité de comprendre éventuellement qu'il y aurait une insulte
dissimulée.

> Peu importe la façon dont est implémentée la couche d'accès aux
> données, elle doit être transparente. Que ce soit des requêtes, des
> appels de proc stock ou quoique ce soit d'autre, rien ne doit être
> redhibitoire.

En quoi une proc stock va apporter un plus pour une bête sélection de
données par rapport à un select classique ?

À rien. Tout à fait à rien. C'est d'ailleurs pour cela que Sybase à inventé
les procédures stockées et que Oracle s'y est mis aussi, c'est parce que cela
n'a aucun intérêt autre que marketting : "Moi aussi je participe au bien-être
des procédures stockées".

> Par exemple ça me ferait mal d'avoir une BD corrompue sous pgSQL ou
> Oracle. Je compte bien faire du BEGIN TRANSACTION/COMMIT. Sinon,
> quel intérêt ?

Quel rapport avec des proc stocks ???

Aucun. Tous les systèmes de stockage de données supportent aussi bien les proc
stoc que les transactions. Et comme cela n'a aucun intérêt, une couche
d'abstraction des SGBD n'a pas à s'embarasser de ces détails inutiles. Donc
inutile de gérer proc stock et transactions.

> Comme ça au moins le SWITCH/CASE sera factorisé dans la couche
> d'abstraction.

Tu veux dire qu'il va falloir reproduire le switch dans toutes les
libs, plutôt qu'une fois dans le code principal, là, ou je suis
complètement à côté de la plaque ?

Il faudrait le reproduire dans libOracle, libSybase, libPgsql etc.

> Ne pas négliger non plus les aspects import/export de base et
> creation/upgrade à l'install.

Ne serait-ce qu'à cause des différences de fonctionnalités et de
gestion des droits selon les différents SGBD, je ne suis de toute
façon pas sûr que ces fonctionnalités très sympa soient portables
totalement. Bien entendu, il faut les conserver sur les SGBD où c'est
possible, mais cela sort du cadre de l'abstraction, puisque ce n'est
pas de l'utilisation quotidienne de SPIP.

Cela dépend de ce que tu appelles "cadre de l'abstraction".

Si tu veux simplement un SPIP qui tourne sous Oracle, histoire de dire "j'ai
une solution et ça tourne sous Oracle", je te le fais en 48h pour 450 Euros.

Maintenant, si tu veux quelque chose qui tire parti du SGBDR choisi, ça
prendra plus de travail, et c'est autrement plus intéressant à faire. Plus
qu'une simple couche d'abstraction de SGBD, ce serait une couche
d'abstraction de fonctionalités de données. Parce que par exemple, un spip
sur un sybase, ce qui serait intéressant :

- Utiliser les transactions pour se mettre à l'abri des corruption de données.
- Utiliser les proc stock pour avoir de meilleures performances (une proc
stock est compilée, et les plans d'exécution sont précalculés dans le cache,
au contraire d'une bête requete SQL).
- permettre (par exemple) grâce à cette transparence fonctionelle
l'utilisation d'un replication server, ce qui apporterait une Haute
Disponibilité et/ou du load balancing sur serveur à forte charge (parce que
ça servirait à quoi de se payer un sybase au lieu d'un Mysql si on a pas un
serveur à fforte charge ???).

Parce que, en ce qui me concerne, déontologiquement, je me refuse à faire du
soft qui est prétendument "compatible Oracle" ou "Sybase", pour qu'en fin de
compte le soft n'utilise que le dénominateur commun le plus petit : MySql. Ce
serait de la microsofterie. Et les microsofteries je ne les fait qu'à
reculons et en me faisant payer. D'ailleurs, quelque part je dois être
convaincant parce que je n'ai pas fait fortune :o)

Jean_Baptiste_FAVRE1 · Novembre 5, 2002, 10:40

Salut,
Je zape l'inutile ;-))

Maintenant, si tu veux quelque chose qui tire parti du SGBDR choisi, ça
prendra plus de travail, et c'est autrement plus intéressant à faire. Plus
qu'une simple couche d'abstraction de SGBD, ce serait une couche
d'abstraction de fonctionalités de données. Parce que par exemple, un spip
sur un sybase, ce qui serait intéressant :

- Utiliser les transactions pour se mettre à l'abri des corruption de données.
- Utiliser les proc stock pour avoir de meilleures performances (une proc
stock est compilée, et les plans d'exécution sont précalculés dans le cache,
au contraire d'une bête requete SQL).
- permettre (par exemple) grâce à cette transparence fonctionelle
l'utilisation d'un replication server, ce qui apporterait une Haute
Disponibilité et/ou du load balancing sur serveur à forte charge (parce que
ça servirait à quoi de se payer un sybase au lieu d'un Mysql si on a pas un
serveur à fforte charge ???).

Parce que, en ce qui me concerne, déontologiquement, je me refuse à faire du
soft qui est prétendument "compatible Oracle" ou "Sybase", pour qu'en fin de
compte le soft n'utilise que le dénominateur commun le plus petit : MySql.

Déontologiquement ou pas, si on me propose plusieurs bases de données possible à l'installation de SPIP, la moindre des choses à
attendre et de tirer parti du SGBD choisi.

Si c'est pour se retrouver avec SPIP sous Oracle ou Postgre et le même système que pour Mysql (les requètes dans le code SPIP), je
n'y vois aucun intérêt.

De deux choses l'une (AMHA), ou on utilise au max les fonctionnalités des SGBD visés, et là je suis partant, ou on fait la petite
couche de vernis pour dire que SPIP est compatible avec tel ou tel SGBD, et là, ben navré si j'en déçois quelques un, mais je
préfère encore MySql que je commence à bien maîtriser.

Les transactions et autres procédures stockée ne sont pas là que pour faire chier le peuple.

Alors oui, c'est peut-être plus compliqué à implémenter, donc ça va peut-être être plus long, mais cela aura au moins le mérite
d'avoir été bien fait et de tenir la route.
Maintenant, ce que j'en dis...
Je ne vise et ne veux vexer personne mais bon, autant pas faire trop de bricolage quand on a la possibilité de faire quelque chose
de propre.

Maintenant, savoir dès maintenant comment on va organiser le code SPIP me paraît quelque peu prématuré. En tout cas à l'aune de mes
connaissances du problème.
Sur ce point particulier, je pense que les développeurs historiques de SPIP pourront nous faire avancer assez rapidement.
@+
JB

63438612493668b99328 · Novembre 5, 2002, 10:59

Salut,

Déontologiquement ou pas, si on me propose plusieurs bases de données possible à l'installation de SPIP, la moindre des choses à
attendre et de tirer parti du SGBD choisi.

Si c'est pour se retrouver avec SPIP sous Oracle ou Postgre et le même système que pour Mysql (les requètes dans le code SPIP), je
n'y vois aucun intérêt.

De deux choses l'une (AMHA), ou on utilise au max les fonctionnalités des SGBD visés, et là je suis partant, ou on fait la petite
couche de vernis pour dire que SPIP est compatible avec tel ou tel SGBD, et là, ben navré si j'en déçois quelques un, mais je
préfère encore MySql que je commence à bien maîtriser.

Pour répondre à ça : justement, à force d'utiliser MySQL
(pour SPIP et pour un autre truc plus volumineux), je suis
à peu près certain qu'il est très largement satisfaisant
pour SPIP ou pratiquement toute autre application de type
"site Web".

Donc, le seul intérêt du multi-bases à mon avis, est de
satisfaire les (dé)goûts personnels ou les besoins professionnels
de certains (ce qui ressortait également de ce que disait
très honnêtement Nicolas Hoizey : il sait que MySQL est tout
à fait à la hauteur, mais certains de ses clients ne jurent
que par Oracle). C'est pour ça aussi que ça m'intéresse
désormais très peu, en tant que développeur, alors que
l'idée m'était plus séduisante fut un temps.

Pour les points précis évoqués ci-dessus :

1. MySQL intègre désormais les transactions donc
le débat est de toute façon caduc de ce côté-là.

2. Utiliser des procédures stockées pour les DBs qui
les supportent revient à dupliquer la logique applicative :
un exemplaire en PHP pour les uns et un exemplaire en
procédures stockées pour les autres. C'est une mauvaise
idée.

ciao

Antoine.

Nicolas_Hoizey1 · Novembre 5, 2002, 11:09

Donc, le seul intérêt du multi-bases à mon avis, est de satisfaire
les (dé)goûts personnels ou les besoins professionnels de certains
(ce qui ressortait également de ce que disait très honnêtement
Nicolas Hoizey : il sait que MySQL est tout à fait à la hauteur,
mais certains de ses clients ne jurent que par Oracle).

+1

1. MySQL intègre désormais les transactions donc le débat est de
toute façon caduc de ce côté-là.

A moitié vrai (ou faux), ce n'est pas nouveau, et peu de gens le
savent et/ou l'utilisent.

2. Utiliser des procédures stockées pour les DBs qui les supportent
revient à dupliquer la logique applicative : un exemplaire en PHP
pour les uns et un exemplaire en procédures stockées pour les
autres. C'est une mauvaise idée.

+1

-Nicolas

Nicolas_Hoizey1 · Novembre 5, 2002, 11:26

Si tu pars comme ça, c'est mal parti...

[...] merci de modérer un peu tes propos ...

Désolé, la prochaine fois, au lieu d'écrire mon mail en 5 minutes,
je le ferait corriger par 2 ou 3 diplomés de science-po, un
diplomate, un avocat et un philologue pour m'assurer qu'il n'y a pas
de virgule mal placée laissant la possibilité de comprendre
éventuellement qu'il y aurait une insulte dissimulée.

Mes plus plates et sincères excuses, j'avais vraiment compris de
travers ta remarque.

Maintenant, répondre aux questions suivantes, que je voulais tout de
même constructives, par de l'ironie de bas étage, ce n'est pas très
intéressant pour qui que ce soit.

Dans mes propos futurs sur le sujet, je tiens donc à dire que je vais
tenter de rester objectif, sachant que j'ai une connaissance partielle
des SGBD "évolués" supportant les procs stocks, transactions et autres
subtilités ...

En quoi une proc stock va apporter un plus pour une bête sélection
de données par rapport à un select classique ?

À rien. Tout à fait à rien. C'est d'ailleurs pour cela que Sybase à
inventé les procédures stockées et que Oracle s'y est mis aussi,
c'est parce que cela n'a aucun intérêt autre que marketting : "Moi
aussi je participe au bien-être des procédures stockées".

Les procédures stockées (à mon sens, donc) servent à exécuter au sein
du SGBD des traitements qui ont intérêt à s'y dérouler. Je ne vois
vraiment pas en quoi une procédure stockée va m'aider à faire un bête
INSERT.

SPIP est une application de gestion de contenu web, pas une
application de gestion financière ...

Par exemple ça me ferait mal d'avoir une BD corrompue sous pgSQL
ou Oracle. Je compte bien faire du BEGIN TRANSACTION/COMMIT.
Sinon, quel intérêt ?

Quel rapport avec des proc stocks ???

Aucun. Tous les systèmes de stockage de données supportent aussi
bien les proc stoc que les transactions. Et comme cela n'a aucun
intérêt, une couche d'abstraction des SGBD n'a pas à s'embarasser de
ces détails inutiles. Donc inutile de gérer proc stock et
transactions.

Toujours à mon sens, proc stocks et transactions n'ont rien à voir.

MySQL supporte d'ailleurs les secondes mais pas les premières. Je
sais, MySQL n'est pas une référence de SGBD "évolué", mais il à
répondu sans faillir à 99% de mes besoins web depuis des années.

Quand au support des transactions dans SPIP, bien sûr qu'il faut y
recourir si c'est disponible, je n'ai jamais été opposé aux
transactions. Seulement, je ne vois vraiment pas le rapport avec les
procs stocks.

Comme ça au moins le SWITCH/CASE sera factorisé dans la couche
d'abstraction.

Tu veux dire qu'il va falloir reproduire le switch dans toutes les
libs, plutôt qu'une fois dans le code principal, là, ou je suis
complètement à côté de la plaque ?

Il faudrait le reproduire dans libOracle, libSybase, libPgsql etc.

C'est donc bien ce que tu proposais, ou c'est encore ironique ?

Si c'est ce que tu proposes, je ne vois pas l'intérêt, et si c'est
ironique, pourrais-tu expliquer cet intérêt que tu y vois ?

Ne serait-ce qu'à cause des différences de fonctionnalités et de
gestion des droits selon les différents SGBD, je ne suis de toute
façon pas sûr que ces fonctionnalités très sympa soient portables
totalement. Bien entendu, il faut les conserver sur les SGBD où
c'est possible, mais cela sort du cadre de l'abstraction, puisque
ce n'est pas de l'utilisation quotidienne de SPIP.

Cela dépend de ce que tu appelles "cadre de l'abstraction".

En effet, et je préfère parler dans le cadre actuel d'indépendance
plutôt que d'abstraction.

Si tu veux simplement un SPIP qui tourne sous Oracle, histoire de
dire "j'ai une solution et ça tourne sous Oracle", je te le fais en
48h pour 450 Euros.

Moi aussi, merci, et même gratos.

Mais je perds toute compatibilité avec les évolutions de SPIP, et de
même pour tous ceux à qui j'aurais eu l'aimable obligeance de donner
le code.

Maintenant, si tu veux quelque chose qui tire parti du SGBDR choisi,
ça prendra plus de travail, et c'est autrement plus intéressant à
faire.

Le but n'est pas de faire quelque chose d'intéressant, mais quelque
chose qui fonctionne.

J'ai plein de projets très intéressants par ailleurs, mais je connais
pas mal de gens qui attendent que SPIP sache tourner sur Oracle pour
l'adopter plutôt qu'un Vignette ou un Documentum.

Plus qu'une simple couche d'abstraction de SGBD, ce serait une
couche d'abstraction de fonctionalités de données. Parce que par
exemple, un spip sur un sybase, ce qui serait intéressant :

- Utiliser les transactions pour se mettre à l'abri des corruption
de données.

Oui.

- Utiliser les proc stock pour avoir de meilleures performances (une
proc stock est compilée, et les plans d'exécution sont précalculés
dans le cache, au contraire d'une bête requete SQL).

Oui.

- permettre (par exemple) grâce à cette transparence fonctionelle
  l'utilisation d'un replication server, ce qui apporterait une
  Haute Disponibilité et/ou du load balancing sur serveur à forte
  charge (parce que ça servirait à quoi de se payer un sybase au
  lieu d'un Mysql si on a pas un serveur à fforte charge ???).

En quoi est-il impossible de faire du load balancing avec MySQL ???

Ce n'est pas parce que ce n'est pas dans une offre packagée toute
jolie que ce n'est pas possible !

OK, je fais de l'ironie, là, mais bon ...

Parce que, en ce qui me concerne, déontologiquement, je me refuse à
faire du soft qui est prétendument "compatible Oracle" ou "Sybase",
pour qu'en fin de compte le soft n'utilise que le dénominateur
commun le plus petit : MySql.

"Déontologiquement" ??? Y'a de l'abus, là ...

Ce serait de la microsofterie. Et les microsofteries je ne les fait
qu'à reculons et en me faisant payer. D'ailleurs, quelque part je
dois être convaincant parce que je n'ai pas fait fortune :o)

Cela ne regarde que toi.

Quoi qu'il en soit, essayons déjà de rendre MySQL indépendant du
stockage de données utilisé, et nous pourrons envisager dans une
seconde phase de penser à une véritable abstraction fonctionnelle, si
tant est que cela soit souhaitable, sans même parler de faisabilité.

-Nicolas

Nicolas_Hoizey1 · Novembre 5, 2002, 11:32

De deux choses l'une (AMHA), ou on utilise au max les
fonctionnalités des SGBD visés, et là je suis partant, ou on fait la
petite couche de vernis pour dire que SPIP est compatible avec tel
ou tel SGBD, et là, ben navré si j'en déçois quelques un, mais je
préfère encore MySql que je commence à bien maîtriser.

TU préfères MySQL, mais c'est sans doute parce que TU as le choix, ce
que d'autres n'ont malheureusement pas ...

Les transactions et autres procédures stockée ne sont pas là que
pour faire chier le peuple.

Non, mais elle ne sont pas forcément pour autant nécessairement à
utiliser à tout va. Sinon, pourquoi peut-on quand même faire du SQL de
base avec les SGBD qui supportent les procs stocks ?

Je ne vise et ne veux vexer personne mais bon, autant pas faire trop
de bricolage quand on a la possibilité de faire quelque chose de
propre.

Pourquoi ce qui est simple, parfaitement fonctionnel et pas trop
ambitieux ne serait-il donc pas "propre" ???

Maintenant, savoir dès maintenant comment on va organiser le code
SPIP me paraît quelque peu prématuré. En tout cas à l'aune de mes
connaissances du problème.

Au bout de six mois de discussions stériles, il serait peut-être bon
d'avancer, au contraire ...

-Nicolas

Herve_LEFEBVRE · Novembre 5, 2002, 11:43

Donc, le seul intérêt du multi-bases à mon avis, est de
satisfaire les (dé)goûts personnels ou les besoins professionnels

Le sujet est donc clôt. Pas de multibase. Ça n'a aucun intérêt. MySQL est
supérieur à tous les Oracle, Sybase, PgSQL réunis.

très honnêtement Nicolas Hoizey : il sait que MySQL est tout
à fait à la hauteur, mais certains de ses clients ne jurent
que par Oracle).

MySQL n'est pas à la hauteur.

1. MySQL intègre désormais les transactions donc
le débat est de toute façon caduc de ce côté-là.

Bien sûr, il est d'ailleurs très fiable sur ce point. C'est pour cela que
cette fonctionalité est toujours mise en avant dès qu'on parle de MySQL.
C'est aussi pour cela que dans SPIP il y a un script pour reconstruire la
database...

2. Utiliser des procédures stockées pour les DBs qui
les supportent revient à dupliquer la logique applicative :
un exemplaire en PHP pour les uns et un exemplaire en
procédures stockées pour les autres. C'est une mauvaise
idée.

Oui, je le dit depuis le début. Les procédures stockées n'ont aucun intérêt.
Elles ont été inventées par le marketting.

Jean_Baptiste_FAVRE · Novembre 6, 2002, 10:04

Pour répondre à ça : justement, à force d'utiliser MySQL
(pour SPIP et pour un autre truc plus volumineux), je suis
à peu près certain qu'il est très largement satisfaisant
pour SPIP ou pratiquement toute autre application de type
"site Web".

Oui, dans 99% des cas.

Donc, le seul intérêt du multi-bases à mon avis, est de
satisfaire les (dé)goûts personnels ou les besoins professionnels
de certains (ce qui ressortait également de ce que disait
très honnêtement Nicolas Hoizey : il sait que MySQL est tout
à fait à la hauteur, mais certains de ses clients ne jurent
que par Oracle). C'est pour ça aussi que ça m'intéresse
désormais très peu, en tant que développeur, alors que
l'idée m'était plus séduisante fut un temps.

L'avantage lorsque l'on a déjà des administrateurs Oracle, c'est qu'on a pas besoin "d'apprendre" MySql.

Pour les points précis évoqués ci-dessus :

1. MySQL intègre désormais les transactions donc
le débat est de toute façon caduc de ce côté-là.

Blague à part, je ne sais plus à partir de quelle version, mais il me semble qu'il s'agit de la 4.x qui n'est toujours pas
considérée comme stable. Me trompe-je ?? (j'espère ;-))

2. Utiliser des procédures stockées pour les DBs qui
les supportent revient à dupliquer la logique applicative :
un exemplaire en PHP pour les uns et un exemplaire en
procédures stockées pour les autres. C'est une mauvaise
idée.

+1
@+
JB

Jean_Baptiste_FAVRE · Novembre 6, 2002, 10:04

Salut,

> De deux choses l'une (AMHA), ou on utilise au max les
> fonctionnalités des SGBD visés, et là je suis partant, ou on fait la
> petite couche de vernis pour dire que SPIP est compatible avec tel
> ou tel SGBD, et là, ben navré si j'en déçois quelques un, mais je
> préfère encore MySql que je commence à bien maîtriser.

TU préfères MySQL, mais c'est sans doute parce que TU as le choix, ce
que d'autres n'ont malheureusement pas ...

Effectivement, j'ai le choix
Et je pense justement que pour certains qui ne l'ont pas forcément, il serait dommage de passer à côté.

> Les transactions et autres procédures stockée ne sont pas là que
> pour faire chier le peuple.

Non, mais elle ne sont pas forcément pour autant nécessairement à
utiliser à tout va. Sinon, pourquoi peut-on quand même faire du SQL de
base avec les SGBD qui supportent les procs stocks ?

Compatibilité ascendante avec des applis non prévues pour ?? ;-))

> Je ne vise et ne veux vexer personne mais bon, autant pas faire trop
> de bricolage quand on a la possibilité de faire quelque chose de
> propre.

Pourquoi ce qui est simple, parfaitement fonctionnel et pas trop
ambitieux ne serait-il donc pas "propre" ???

Là n'est pas le problème.
Le problème AMHA, et il ne s'agit que de mon sentiment personnel, c'est que si les proc stockées et autres existent, il faut les
prendre en compte: on n'a pas à imposer un choix technique.
Effectivement, c'est sans doute plus facile à implémenter et dans le cas de SPIP, aucunement obligatoire.
Mais de la même façon que certains ne jurent que par Oracle, d'autre, j'en connais, ne jurent que par les procs stockées et autres
transactions. Du coup, MySql leur apparaît comme un SGBD de bas étage ;-D
Pour ces gens là, il faudrait donc coller au plus près des possibilités techniques des SGBD.

> Maintenant, savoir dès maintenant comment on va organiser le code
> SPIP me paraît quelque peu prématuré. En tout cas à l'aune de mes
> connaissances du problème.

Au bout de six mois de discussions stériles, il serait peut-être bon
d'avancer, au contraire ...

<Blague>
C'est pas ce qu'on essaye de faire ??
</Blague>

Jean_Baptiste_FAVRE · Novembre 6, 2002, 10:38

Bonjour,

Bonjour,

En revanche, les vues sont très intéressantes pour rendre transparentes
les jointures. Dans tous les cas on fait un select/insert/delete/update
dans la vue, c'est le SGBDR qui se débrouille pour gérer la syntaxe qui
lui est propre pour les jointures. Autrement dit, Autrement dit, on gère le
maximum de spécifique au SGBD lors de la création des objets SQL,
exactement dans le même principe que les procédures stockées.
Les procédures stockées n'ont d'intérêt réel en architecture trois tiers
que s'il y a plusieurs middle-tiers (en fait on se ramène au schéma deux
tiers). Par exemple, si on devait avoir accès aux mêmes données de la
même manière sous PHP, PERL et (osons !) ASP, il est clair qu'on aurait
intérêt à centraliser le SQL dans la base en non dans les scripts.

> > C'est d'ailleurs pour cela que Sybase à
> > inventé les procédures stockées et que Oracle s'y est mis aussi,

Ils ont aussi inventé les BLOB, alors éviter de prendre les inventions à
la con des éditeurs de logiciels pour du pain béni et sans garder
d'esprit critique. Et ce genre de bidules n'a d'intérêt que pour gérer
les fichiers sur les DMZ de manière transparente, ce qui est très
faible.

+1

> Les procédures stockées (à mon sens, donc) servent à exécuter au sein
> du SGBD des traitements qui ont intérêt à s'y dérouler. Je ne vois
> vraiment pas en quoi une procédure stockée va m'aider à faire un bête
> INSERT.
Le code SQL doit être quelque part dans l'application (hop, une porte
ouverte enfoncée). C'est ensuite un CHOIX de design que de le mettre
dans la base directement, ou dans le client (une horreur pour gérer les
versions et le déploiement) ou dans un "middle-tiers" comme PHP.

> >>> Par exemple ça me ferait mal d'avoir une BD corrompue sous pgSQL
> >>> ou Oracle. Je compte bien faire du BEGIN TRANSACTION/COMMIT.
> >> Quel rapport avec des proc stocks ???
Aucun. On peut/doit utiliser des transactions dans n'importe quel
modèle, que ce soit en requêtes directes ou en proc stock.

> Toujours à mon sens, proc stocks et transactions n'ont rien à voir.
Je confirme, Nico, ça n'a RIEN à voir.

> >> Ne serait-ce qu'à cause des différences de fonctionnalités et de
> >> gestion des droits selon les différents SGBD, je ne suis de toute
> >> façon pas sûr que ces fonctionnalités très sympa soient portables
> >> totalement.

La gestion des droits foutra potentiellement plus le bordel AVEC des
proc stockées. En effet, il faudra s'assurer que les hébergeurs donnent
le droit de les exécuter, ce qui peut potentiellement ne pas être le
cas.

Corrigez moi si je me trompe, mais je ne connais pas d'hébergeur qui propose Postgresql ou Oracle.
Maintenant, dans les entreprises, il est plus que probable qu'il y aura matière à concialiation, non ??
D'autant que dans certains cas, l'administrateur Web et le DBA, s'il ne sont pas une seule et unique personne, sont assez souvent
proche géographiquement l'un de l'autre.

> > - Utiliser les proc stock pour avoir de meilleures performances (une
> > proc stock est compilée, et les plans d'exécution sont précalculés
> > dans le cache, au contraire d'une bête requete SQL).
Attention à ce point : les plans d'exécutions sont tellement bien
précalculés qu'ils utilisent les statistiques de remplissage des tables
au moment de la compilation de la procédure stockée. Le résultat est
donc que pour garder des performances constantes, on est obligés de les
recompiler toutes les semaines ou à défaut avec un taux de remplissage
moyen cohérent.

Sinon, s'ils utilisent les statistiques courantes... et bien ils
recalculent le plan d'exécution comme si c'était une requête arrivant
d'un client externe.

> > - permettre (par exemple) grâce à cette transparence fonctionelle
> > l'utilisation d'un replication server,

Je ne vois pas le lien avec un spip multibase ?

Disons juste, je suis en train de découvrir le vaste sujet de la réplication de base, qu'il semblerait beaucoup plus "facile" à
mettre en place avec Oracle ou Postgresql qu'avec MySql.
Je que je sais en tout cas, c'est que Mysql ne propose une réplication que dans un sens. Il est fortement déconseillé de faire du
"two-ways" comme il l'appellent.
Peut-être qu'Oracle et Postgresql proposent des outils de consolidation de façon native ?
La balle est dans le camps des spécialistes SGBD.

Il est des entreprises où on utilise ce qu'on a. Une license Oracle ou
Sybase est nécessaire pour d'autres applications, la base est là, déjà
administrée, backupée avec redondances et tout le bazar, ajouter un
autre SGBD sur une machine de PRODUCTION (je parle pas des bidouilles
perso) a un coût qui n'est pas envisagé, ni envisageable. C'est bien de
défendre les logiciels libres mais il faut aussi faire avec les réalités
de ce bas monde, et je préfère pouvoir installer spip sur une base
Oracle que de ne pas pouvoir l'installer du tout.

Ces boîtes là ont donc sûrement des administrateurs formés et compétents sur ces systèmes.
Ils souhaiteront peut-être utiliser les procks stockées, les transactions, vues et autres triggers.
Alors, j'admet que, dans un premier temps, on fasse quelque chose qui "marche".
Mais il serait dommage de s'arrêter là, non ?
Cela permettrait d'enrichir encore le système, de le rendre plus ... crédible.
A ce sujet, petite anecdote de bureau:
§J'étais en train de mettre en place un site SPIP et , tant qu'à faire, de regarder les bases des autres.
§Un de mes chefs passe dans le bureau pour m'expliquer qu'une division (appelons ça comme ça) de la boîte
§souhaite un site de publication documentaire.
§Pas de problème, on va proposer SPIP.
§Et là, surprise, la réponse: Ben en fait, ils sont pas trop pour parce qu'ils pensent que MySql est pas assez
§costaud, et pis gnagnagna....
§Je vous passe les détails, mais enquète faite, je m'aperçois que, dans la fameuse division, un type avait eu la
§bonne idée (pour le coup c'est vrai qu'elle était bonne) de se renseigner sur le comment du problème, avait
§donc lu en diagonale la listes des fonctionnalités MySql et Oracle et autres, et en avait donc "logiquement"
§conclu que MySql n'était pas à la auteurs.
§Pensez-donc: utiliser le même SGBD que des sites Persos ??? Pas question.
§Alors voilà, le problème pour certains, c'est l'image du produit.
Donc, si on arrive à faire en sorte (et calmement ;-)) de rendre SPIP compatible et si
possible/faisable/rentable... plus, alors on gagnera encore en terme d'image, non ??
@+
JB

3c1eb9c256e5f950e230 · Novembre 6, 2002, 2:02

Salut.

Mes 2 centimes d'euros.

La replication MySql fonctionne très bien et est très facile à mettre en place, voir www.mysql.com où il y a un tutoriel très facile d'accès.
Seul bémol, attention à votre version de mysql, certaines versions anciennes avaient des problemes lors des modifications de structure de la base.

Le principe est: 1 master et autant de 'slave' que désiré.
Toutes les ecritures se font sur le master, les lectures peuvent être reparties sur les slaves.
En cas de plantage du master, on peut via un script php reattribuer à la volée le role de master à un des 'slaves'.

Cela fonctionne en prod chez nous depuis un an, et tout marche à merveille (sur un appli PHP métier, pas avec SPIP).
Notre base compte à peu près 400 tables variant de quelques enregistrements à 12 ou 13 millions.

a+

Olivier'
www.blairinette.com (thanx to SPIP)

John_Gallet · Novembre 6, 2002, 2:54

Re,

Corrigez moi si je me trompe, mais je ne connais pas d'hébergeur qui propose Postgresql ou Oracle.

Il y en a pourtant un nombre certain. http://www.abchebergement.com/
Ne pas confondre en revanche "hébergement" et "hébergement gratuit"...

D'autant que dans certains cas, l'administrateur Web et le DBA,
s'il ne sont pas une seule et unique personne, sont assez souvent
proche géographiquement l'un de l'autre.

Tout dépend de la taille de l'entreprise/du groupe. Et dans tous les
cas, la question est de faire le bon choix technologique pour la
maintenance future de Spip, pas pour faire plaisir à untel ou untel (y
compris moi, qui n'ai dans l'affaire aucun intérêt particulier à faire
adopter telle ou telle solution, je ne fais que donner un avis technique
et je vais vite retourner me coucher en read only de la liste).

Disons juste, je suis en train de découvrir le vaste sujet de la
réplication de base, qu'il semblerait beaucoup plus "facile"
à mettre en place avec Oracle ou Postgresql qu'avec MySql.

Ca dépend. Sous Oracle, en Entreprise Edition, fastoche, il suffit de
mettre la base en archivelogs avec une des 5 destinations des logs
distante et égale à l'alimentation de la base en répli.
En Standard Edition, il faut faire des transferts FTP en crontab et tout
gérer "à la mimine".
Sous Sybase, il faut un produit en plus, mais ça se gère pas trop mal
(modulo les bugs Sybase de la répli qui sont incapables de rejouer les
mêmes requêtes, donc se vautrent régulièrement sur la gestion des float
vs numériques car Sybase n'a jamais éta capable de gérer ses floats
correctement, mais c'est une autre histoire).
Sous PostGres, je n'ai pas d'expérience de production.

Je que je sais en tout cas, c'est que Mysql ne propose une réplication que dans un sens.

Dans tous les cas (lire : quel que soit le SGBDR), faire de la
réplication en load balancing avec mises à jour possibles sur plusieurs
machines comporte des risques, voire n'est pas toléré par le SGBD. La
seule utilisation "safe" d'un replication serveur est soit en hot backup
(si la machine de prod se vautre, l'autre est dispo) soit en lecture
seule dans le serveur en réplication esclave.

Je ne parle pas ici des solutions de base en cluster réel ou la base est
répartie entre plusieurs machines de manière transparente bien entendu
(exemple, la solution d'Oracle 9 sous Cluster True64 unix qui est une
merveille technologique pour les applications sensibles à très haute
dispo).

Peut-être qu'Oracle et Postgresql proposent des outils de consolidation de façon native ?
La balle est dans le camps des spécialistes SGBD.

Je ne vois toujours pas le lien avec le fait que spip soit utilisable
aussi avec Oracle, PostGres ou Sybase en plus de Mysql. C'est bien de ça
qu'il est question ou j'ai loupé un épisode ? Qu'ensuite, au sein d'un
accès à un type/une marque de SGBD, les lectures aient lieu sur un
serveur, et les modifications sur un autre, c'est une autre affaire.

Ces boîtes là ont donc sûrement des administrateurs formés et compétents sur ces systèmes.
Ils souhaiteront peut-être utiliser les procks stockées, les transactions, vues et autres triggers.

Ils peuvent souhaiter tout ce qu'ils veulent : on leur donne un produit
(spip) qui a un certain mode de fonctionnement. Le fait qu'il utilise ou
non 100% des gadgets ou trucs super utiles de la base n'est pas un
critère de qualité du produit. De plus,trop rares sont les DBAs qui sont
de vrais développeurs à l'origine (normal, être DBA est un métier à part
entière).

Je travaille au quotidien sur un logiciel qui équipe 90% des ebrokers de
France et de Navarre. Le même code tourne sous Unix, NT, VMS, avec
Oracle, Sybase, SQL-Server, RDB. Il est clair qu'il n'utilise que le
plus petit dénominateur commun des fonctionnalités de ces SGBD et
systèmes d'exploitation pour rester portable/compatible.

Alors, j'admet que, dans un premier temps, on fasse quelque chose qui "marche".
Mais il serait dommage de s'arrêter là, non ?

Sauf si je ne m'abuse, la philosophie de développement de spip a
toujours été de rendre transparents les points techniques pour se
concentrer sur le confort de l'utilisateur.
En l'occurence, qu'est ce que le gars qui saisi son article en a à f...
qu'il déclenche un insert en client/serveur, en proc stock, ou en
trigger ? Son service informatique, lui, a besoin qu'il s'intègre dans
l'existant. Du moment que l'utilisateur peut aller voir son DSI en lui
disant "j'ai besoin d'un produit nouveau, mais pas de soucis il est
compatible avec l'existant", le produit en question est adopté à 50%.
S'il commence par lui dire "il va falloir installer un nouveau SGBD", il
part avec un handicap de refus à 50%...

Cela permettrait d'enrichir encore le système, de le rendre plus ... crédible.

Ce point est important (crédibilité). Mais si déjà il était possible de
dire 'compatible avec les SGBD les plus utilisés du marché' pensez vous
vraiment que les décideurs qui vont choisir Spip pour ses
fonctionnalités vont aller se demander s'il utilise ou non des triggers
? (pour autant qu'ils sachent que ça existe...)

§Je vous passe les détails, mais enquète faite, je m'aperçois que, dans la fameuse division, un type avait eu la
§bonne idée (pour le coup c'est vrai qu'elle était bonne) de se renseigner sur le comment du problème, avait
§donc lu en diagonale la listes des fonctionnalités MySql et Oracle et autres, et en avait donc "logiquement"
§conclu que MySql n'était pas à la auteurs.

Et là dessus l'effet de crédibilité joue : regardez, spip fonctionne
avec Oracle et c'est gagné.

Donc, si on arrive à faire en sorte (et calmement ;-)) de rendre SPIP compatible et si
possible/faisable/rentable... plus, alors on gagnera encore en terme d'image, non ??

Je n'ai pas pour habitude de forcer qui que ce soit à accepter ou non
mon opinion, que j'ai déjà donnée, je ne recommencerai donc pas.

Souvenez vous simplement pour le choix technique que :

- être capable de tourner sur les "grands" SGBD du marché sera la seule
chose qui sera vue (qui va aller se palucher le code de spip avant de le
choisir ?)

- ce qui coûte le plus cher en temps homme de développement, c'est la
maintenance/évolution du produit, autrement dit l'ennemi numéro un est
la duplication de code en N versions, sans compter les bugs qui
apparaissent dans une version et pas dans une autre. La solution la plus
appropriée sera donc celle qui minimise les modifications pour une même
requête SQL à gérer.

- à chaque problème la solution technique qui lui est la plus adaptée. A
mon sens, l'utilisation de procédures stockées ne l'est pas **dans le
cas précis de spip** (j'ai bouffé suffisament de procédures stockées
pour, en revanche, refuser de m'en passer dans d'autres cas). Pour
rappel, chaque SGBD a son propre langage de procédures stockées, qui ne
sont pas compatibles entre eux.

- On peut oublier ma suggestion de l'utilisation des vues, car Mysql ne
les implémente pas encore. Ou alors il sera possible de les utiliser
pour gérer de manière uniforme tous les SGBD qui les supportent. La
solution technique la moins coûteuse en temps me semble donc la couche
d'abstraction gérée par PHP, quitte à ce qu'elle soit restreinte aux
besoins de Spip (i.e. il ne s'agit pas de développer une super couche
générique acceptant toutes les requêtes SQL pour tous les SGBD du
marché).

a++
JG

From Gilles.Perez@univ-montp3.fr Wed Nov 6 16:00:14 2002

Return-Path: <Gilles.Perez@univ-montp3.fr>
Received: from smtp.univ-montp3.fr (smtp.univ-montp3.fr [193.52.140.45])
  by miel.brainstorm.fr (Postfix) with ESMTP
  id 7AF2E1D405; Wed, 6 Nov 2002 16:00:14 +0100 (CET)
Received: from univ-montp3.fr (localhost [127.0.0.1])
  by smtp.univ-montp3.fr (8.11.6/linuxconf) with ESMTP id gA6Emm623282;
  Wed, 6 Nov 2002 15:48:48 +0100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
In-Reply-To: <20021105203140.GC19837@rezo.net>
Message-Id: <8900D4FF-F198-11D6-B87B-000A27B468AA@univ-montp3.fr>
Content-Transfer-Encoding: quoted-printable
X-Mailer: Apple Mail (2.546)
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1b3+
Precedence: list
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Archive: <Discuter chez rezo.net;
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=subscribe>
List-Post: <mailto:spip-dev@rezo.net>
List-Id: SPIP : developpement <spip-dev.rezo.net>
X-List-Received-Date: Wed, 06 Nov 2002 15:00:14 -0000
Status: O
Content-Length: 1078
Lines: 32

Bonjour,

Le mardi, 5 nov 2002, =E0 21:31 Europe/Paris, Fil a =E9crit :

__________________________________________________________
(...)
Post-scriptum : X Oui O Non
Date de publication ant=E9rieure : O Oui X Non
[...]
quelque chose de lisible/rep=E9rable/explicite (+ que champ X)
par contre cot=E9 squelettes les balises seraient du genre (pas
renommable) : #CHAMP1 #CHAMP2 #CHAMP3 ...

- quels objets peut-on =E9tendre ? tous ? seulement les articles ?

Pourrait-on pr=E9voir des types d'article=A0? Au moment o=F9 on saisit =
pour=20
la premi=E8re fois un article (et tant que tous les champs -- hors titre=20=

-- sont vides), on choisit le type de l'article... =C7a permettrait de=20=

pouvoir d=E9finir des articles de type =AB=A0Ouvrage=A0=BB auxquels, en =
plus des=20
champs standards de Spip, on pourrait rajouter I.S.B.N., prix, etc. Si=20=

c'est un test de jeu, d'autres champs, etc.

- ???

Mais je crois que la proposition de types d'article est plut=F4t pour=20
Spip 2.0, non=A0?

Gilles.=

Jean_Baptiste_FAVRE · Novembre 6, 2002, 3:07

Ouais, ben moi je vais retourner à l'école alors ;-))
C'est dans ces cas là que l'on entrevoit l'étendue de notre ignorance.
Soit dit sans sous-entendus scabreux, évidemment.
Chapeau pour l'analyse et l'objectivité en tout cas.
@+
JB

Thomas_NOEL · Novembre 6, 2002, 3:47

Du moment que l'utilisateur peut aller voir son DSI en lui
disant "j'ai besoin d'un produit nouveau, mais pas de soucis il est
compatible avec l'existant", le produit en question est adopté à 50%.
S'il commence par lui dire "il va falloir installer un nouveau SGBD", il
part avec un handicap de refus à 50%...

C'est quoi la différence exacte entre un produit accepté à 50% et un
produit refusé à 50% ?

Pour prendre part à la discussion, ajouter une couche d'abstraction (une
sorte de "SGBD virtuel") en prenant le plus petit dénominateur commun ne
devrait pas nous faire bondir. Pensons à toutes ces machines virtuelles
telles que nos systèmes d'exploitation Unix. Aucune n'exploite
systématiquement la puissance réelle du matériel... Pourquoi
développons-nous en PHP alors qu'on pourrait tout faire en assembleur
pour utiliser les MMX et autres 3DNow de nos pécés Intel ?

a+

John_Gallet · Novembre 6, 2002, 4:04

Re,

<mode pas_serieux="on">

Idem.

C'est quoi la différence exacte entre un produit accepté à 50% et un
produit refusé à 50% ?

Le produit qui a 50% d'acceptation n'a plus que 50% du chemin à faire
pour être accepté.
Celui qui part avec le refus de 50% n'a plus que 50% du chemin à faire
pour être... refusé, et 150% pour être quand même accepté après moult
discussions de marchands de tapis.

Autrement dit, si on commence par dire à un DSI qu'il va lui falloir un
autre SGBD pour gérer une application, il commence par dire "Hors de
question" d'abord, et si on lui casse les c^W pieds il regardera *peut
être* quand même le produit. Si il est de bon poil (i.e. Paméla, la
secrétaire du patron, a été gentille aujourd'hui). Si on lui dit que
tout est prêt pour accueillir le même nouveau logiciel, il passera
probablement en mode "Rien A Foutre, une appli de plus, affaire classée,
ok pour moi du moment qu'on a la place disque".

développons-nous en PHP alors qu'on pourrait tout faire en assembleur
pour utiliser les MMX et autres 3DNow de nos pécés Intel ?

TST SIGNATURE 1
BRA SIGNATURE
JMP 0xFFF

John_Gallet · Novembre 6, 2002, 4:16

Pas de remarques sexistes sur les listes de spip, svp. Merci pour tou(te)s !

Mes excuses à tou(te)s.
JG

From professeur_ses@ifrance.com Wed Nov 6 18:05:25 2002

Return-Path: <professeur_ses@ifrance.com>
Received: from th06.opsion.fr (th06.opsion.fr [62.39.122.16])
  by miel.brainstorm.fr (Postfix) with SMTP id 559371D4C6
  for <spip-dev@rezo.net>; Wed, 6 Nov 2002 18:05:25 +0100 (CET)
Received: from 81.49.45.108 [81.49.45.108] by th06.opsion.fr id
  200211061705.0ec7; Wed, 6 Nov 2002 17:05:14 GMT
X-Mailer: The Bat! (v1.60c)
Organization: CyBerSES
X-Priority: 3 (Normal)
Message-ID: <11587640609.20021106180521@ifrance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1b3+
Precedence: list
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Archive: <Discuter chez rezo.net;
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=subscribe>
List-Post: <mailto:spip-dev@rezo.net>
List-Id: SPIP : developpement <spip-dev.rezo.net>
X-List-Received-Date: Wed, 06 Nov 2002 17:05:25 -0000
Status: O
Content-Length: 795
Lines: 24

Bonjour à tous,

J'ai installé les nouveaux squelettes d'Antoine qui sont trés
pratiques tout en restant sobre (en 2 mots Bravo Antoine )

Néanmoins je signale un petit soucis, le bouton recalculer (et même
celui des stats pour les articles) reste inaccessible, car il va se
mettre derrière le menu de navigation au lieu d'être en bas à gauche.

Bonne continuation et Mille fois Merci pour ce super script

PS: pourquoi SPIP n'est-il pas reconnu d'intérêt pédagogique par l'EN ?
les auteurs y sont-ils opposés ?