Tout d'abord, je post =E0 la fois dans fr.comp.applications.sgbd et
fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je
positionne le suivis plutot dans fcl.php. (avec l'espoire que ma
question y trouve sa place :-) )
Bon, je vais prochainement r=E9aliser une base de donn=E9es. Je souhaite la
faire en xml (j'ai envie ! et je suis motiv=E9 par ce choix... bref, j'ai
mes raisons). Seulement, j'ai peur qu'il y ait des concurrences si
plusieurs clients se connectent au site (et donc =E0 la BDD).
Voici en r=E9sum=E9 le type de donn=E9es que je souhaite avoir dans mon xml=
:
<users>
<user>
<nom>xxxx</nom>
<email>xxxx</email>
... ... etc etc
</user>
<user>
<nom>yyyy</nom>
<email>yyyy</email>
... ... etc etc
</user>
</users>
En fait, j'ai peur que si mon utilisateur "xxxx" change son email en
m=EAme temps que "yyyy" change son nom : alors mon script PHP va
probablement faire un conflit =E0 un utilisateur ou =E0 l'autre...
J'ai une premi=E8re id=E9e de solution en t=EAte : il "suffirait" de
bloquer/retarder l'=E9criture si le fichier est en lecture. (cela n'=E0 peu=
t
=EAtre rien =E0 voir, mais j'ai entendu parl=E9 du flock.. c'est =E0 cela q=
ue =E7a
sert ??).
Je ne sais pas si cette m=E9thode serait bien car elle ralentirai beaucoup
d'autres utilisateurs...
Une autre m=E9thode que j'ai d=E9j=E0 employ=E9e par le pass=E9 : faire un =
fichier
xml pour chacun de mes utilisateur. (et alors il faudrait qu'un m=EAme
utilisateur se connecte 2 fois =E0 son compte et modifie au m=EAme instant
ses donn=E9es pour que l'on se retrouve dans le cas pr=E9c=E9dent.. mais ce=
la
limite quand m=EAme beaucoup...) Et surtout, c'est pas pratique =E0
utiliser, car pour avoir la liste des utilisateurs, il faut que le
script lise la totalit=E9 des petits fichiers un =E0 un...
Alors, que me conseillez vous ?
Et comment faites vous ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Mevzek
Le Thu, 15 Mar 2007 16:22:55 +0100, Newsgroups a écrit :
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et fr.comp.lang.php.
Personnellement, je pense aucun des deux ne convient mais bref.
Pas vu de suivi.
Bon, je vais prochainement réaliser une base de données. Je souhaite la faire en xml (j'ai envie ! et je suis motivé par ce choix... bref, j'ai mes raisons).
Ca veut dire quoi faire une base de données en XML ? Utiliser un SGBD orienté purement XML ? Utiliser un SGBDR avec une extension XML ? Stocker un document XML dans un SGBDR quelconque ?
Seulement, j'ai peur qu'il y ait des concurrences si plusieurs clients se connectent au site (et donc à la BDD).
Voici en résumé le type de données que je souhaite avoir dans mon xml : <users> <user> <nom>xxxx</nom> <email>xxxx</email> ... ... etc etc </user> <user> <nom>yyyy</nom> <email>yyyy</email> ... ... etc etc </user> </users>
Je ne vois pas bien l'intérêt de stocker ca sous cette forme dans la base. Si vous avez besoin des informations sous cette forme vous pouvez toujours les recréer à partir des données dans la base sous une forme normale (si on prend le cas d'un SGBDR, on aurait donc des tuples user, avec des attributs nom et email).
Tout le reste se déduit à mon avis de ce problème.
Noter que les problèmes d'accès concurrent à partir du moment où vous utilisez un SGBD (R ou pas) sont a priori du ressort du SGBD, qui doit en théorie mettre en oeuvre les procédures adéquates en ce sens. Mais c'est plus ou moins bien géré (selon ce qu'on veut exactement comme accès concurrents).
Une autre méthode que j'ai déjà employée par le passé : faire un fichier xml pour chacun de mes utilisateur. (et alors il faudrait qu'un même utilisateur se connecte 2 fois à son compte et modifie au même instant ses données pour que l'on se retrouve dans le cas précédent.. mais cela limite quand même beaucoup...)
Ce genre de réflexions crééent des heisenbugs, les pires à débusquer. Il ne faut pas raisonner comme ca.
Alors, que me conseillez vous ?
De vous poser cinq minutes, avec un papier et un crayon, d'éliminer XML et PHP (on se demande d'ailleurs ce que ce dernier vient faire là, on n'a parlé que de SGBD jusqu'à présent), et de réflechir à votre système en tant qu'ensemble : qu'est-ce que vous voulez stocker, sous quelle forme, comment le récupérer, sous quelle forme, etc...
Et comment faites vous ?
Personnellement, j'utilise PostgreSQL qui gère comme un charme les accès concurrents avec les niveaux d'isolation prévus par le standard SQL. Il dispose de plus d'une extension XML (pour le cas où l'on veut vraiment stocker un document XML sans qu'il soit considéré comme un bloc de texte opaque par le SGBDR), que je n'ai pas encore utilisé (même s'il m'arrive de produire des bouts de XML à partir de données dans des tables, ce qui recoupe ce que je vous disais plus haut en terme de séparer comment les choses sont stockées de comment elles sont formatées lors d'une récupération).
Bon courage dans votre réflexion en tout cas.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Thu, 15 Mar 2007 16:22:55 +0100, Newsgroups a écrit :
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et
fr.comp.lang.php.
Personnellement, je pense aucun des deux ne convient mais bref.
Pas vu de suivi.
Bon, je vais prochainement réaliser une base de données. Je souhaite la
faire en xml (j'ai envie ! et je suis motivé par ce choix... bref, j'ai
mes raisons).
Ca veut dire quoi faire une base de données en XML ?
Utiliser un SGBD orienté purement XML ?
Utiliser un SGBDR avec une extension XML ?
Stocker un document XML dans un SGBDR quelconque ?
Seulement, j'ai peur qu'il y ait des concurrences si
plusieurs clients se connectent au site (et donc à la BDD).
Voici en résumé le type de données que je souhaite avoir dans mon xml :
<users>
<user>
<nom>xxxx</nom>
<email>xxxx</email>
... ... etc etc
</user>
<user>
<nom>yyyy</nom>
<email>yyyy</email>
... ... etc etc
</user>
</users>
Je ne vois pas bien l'intérêt de stocker ca sous cette forme dans la
base. Si vous avez besoin des informations sous cette forme vous pouvez
toujours les recréer à partir des données dans la base sous une forme
normale (si on prend le cas d'un SGBDR, on aurait donc des tuples user,
avec des attributs nom et email).
Tout le reste se déduit à mon avis de ce problème.
Noter que les problèmes d'accès concurrent à partir du moment où vous
utilisez un SGBD (R ou pas) sont a priori du ressort du SGBD, qui doit en
théorie mettre en oeuvre les procédures adéquates en ce sens.
Mais c'est plus ou moins bien géré (selon ce qu'on veut exactement comme
accès concurrents).
Une autre méthode que j'ai déjà employée par le passé : faire un
fichier xml pour chacun de mes utilisateur. (et alors il faudrait qu'un
même utilisateur se connecte 2 fois à son compte et modifie au même
instant ses données pour que l'on se retrouve dans le cas précédent..
mais cela limite quand même beaucoup...)
Ce genre de réflexions crééent des heisenbugs, les pires à débusquer.
Il ne faut pas raisonner comme ca.
Alors, que me conseillez vous ?
De vous poser cinq minutes, avec un papier et un crayon, d'éliminer XML
et PHP (on se demande d'ailleurs ce que ce dernier vient faire là, on n'a
parlé que de SGBD jusqu'à présent), et de réflechir à votre système
en tant qu'ensemble : qu'est-ce que vous voulez stocker, sous quelle
forme, comment le récupérer, sous quelle forme, etc...
Et comment faites vous ?
Personnellement, j'utilise PostgreSQL qui gère comme un charme les accès
concurrents avec les niveaux d'isolation prévus par le standard SQL.
Il dispose de plus d'une extension XML (pour le cas où l'on veut vraiment
stocker un document XML sans qu'il soit considéré comme un bloc de texte
opaque par le SGBDR), que je n'ai pas encore utilisé (même s'il m'arrive
de produire des bouts de XML à partir de données dans des tables, ce qui
recoupe ce que je vous disais plus haut en terme de séparer comment les
choses sont stockées de comment elles sont formatées lors d'une
récupération).
Bon courage dans votre réflexion en tout cas.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Thu, 15 Mar 2007 16:22:55 +0100, Newsgroups a écrit :
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et fr.comp.lang.php.
Personnellement, je pense aucun des deux ne convient mais bref.
Pas vu de suivi.
Bon, je vais prochainement réaliser une base de données. Je souhaite la faire en xml (j'ai envie ! et je suis motivé par ce choix... bref, j'ai mes raisons).
Ca veut dire quoi faire une base de données en XML ? Utiliser un SGBD orienté purement XML ? Utiliser un SGBDR avec une extension XML ? Stocker un document XML dans un SGBDR quelconque ?
Seulement, j'ai peur qu'il y ait des concurrences si plusieurs clients se connectent au site (et donc à la BDD).
Voici en résumé le type de données que je souhaite avoir dans mon xml : <users> <user> <nom>xxxx</nom> <email>xxxx</email> ... ... etc etc </user> <user> <nom>yyyy</nom> <email>yyyy</email> ... ... etc etc </user> </users>
Je ne vois pas bien l'intérêt de stocker ca sous cette forme dans la base. Si vous avez besoin des informations sous cette forme vous pouvez toujours les recréer à partir des données dans la base sous une forme normale (si on prend le cas d'un SGBDR, on aurait donc des tuples user, avec des attributs nom et email).
Tout le reste se déduit à mon avis de ce problème.
Noter que les problèmes d'accès concurrent à partir du moment où vous utilisez un SGBD (R ou pas) sont a priori du ressort du SGBD, qui doit en théorie mettre en oeuvre les procédures adéquates en ce sens. Mais c'est plus ou moins bien géré (selon ce qu'on veut exactement comme accès concurrents).
Une autre méthode que j'ai déjà employée par le passé : faire un fichier xml pour chacun de mes utilisateur. (et alors il faudrait qu'un même utilisateur se connecte 2 fois à son compte et modifie au même instant ses données pour que l'on se retrouve dans le cas précédent.. mais cela limite quand même beaucoup...)
Ce genre de réflexions crééent des heisenbugs, les pires à débusquer. Il ne faut pas raisonner comme ca.
Alors, que me conseillez vous ?
De vous poser cinq minutes, avec un papier et un crayon, d'éliminer XML et PHP (on se demande d'ailleurs ce que ce dernier vient faire là, on n'a parlé que de SGBD jusqu'à présent), et de réflechir à votre système en tant qu'ensemble : qu'est-ce que vous voulez stocker, sous quelle forme, comment le récupérer, sous quelle forme, etc...
Et comment faites vous ?
Personnellement, j'utilise PostgreSQL qui gère comme un charme les accès concurrents avec les niveaux d'isolation prévus par le standard SQL. Il dispose de plus d'une extension XML (pour le cas où l'on veut vraiment stocker un document XML sans qu'il soit considéré comme un bloc de texte opaque par le SGBDR), que je n'ai pas encore utilisé (même s'il m'arrive de produire des bouts de XML à partir de données dans des tables, ce qui recoupe ce que je vous disais plus haut en terme de séparer comment les choses sont stockées de comment elles sont formatées lors d'une récupération).
Bon courage dans votre réflexion en tout cas.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
mordicus
Newsgroups a écrit :
Bonjour,
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je positionne le suivis plutot dans fcl.php. (avec l'espoire que ma question y trouve sa place :-) )
[SNIP]
AHAHAH, merci, on a bien rigoler au bureau, c'est excellent ! ;)
Newsgroups a écrit :
Bonjour,
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et
fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je
positionne le suivis plutot dans fcl.php. (avec l'espoire que ma
question y trouve sa place :-) )
[SNIP]
AHAHAH, merci, on a bien rigoler au bureau, c'est excellent ! ;)
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je positionne le suivis plutot dans fcl.php. (avec l'espoire que ma question y trouve sa place :-) )
[SNIP]
AHAHAH, merci, on a bien rigoler au bureau, c'est excellent ! ;)
Jean-Marc Molina
Newsgroups wrote:
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je positionne le suivis plutot dans fcl.php. (avec l'espoire que ma question y trouve sa place :-) )
Il manque le suivi sur le groupe PHP. Peut-être qu'il aurait fallu "cross-poster" sur le groupe XML plûtôt.
Bon, je vais prochainement réaliser une base de données. Je souhaite la faire en xml (j'ai envie ! et je suis motivé par ce choix... bref, j'ai mes raisons). Seulement, j'ai peur qu'il y ait des concurrences si plusieurs clients se connectent au site (et donc à la BDD).
Il ne faut pas mélanger BDD et SGBD. Le SGBD permet justement de gérer la concurrence au sein de BDDs, entre autre chose. La BDD ne reste qu'un ensemble organisé de données. Pour les SGBD XML voir du côté de Xindice, Berkeley DB XML, eXist... Par contre je n'ai jamais essayé d'utiliser ces SGBD avec PHP, en Java uniquement.
Par contre je pense que la gestion de données en PHP à l'aide d'un fichier au format XML reste un très bon exercice pour apprendre ces sujets. Par contre il ne faut pas considérer qu'un script PHP et un fichier XML remplace un SGBDR comme MySQL ou SQLite. Comme solution hybride vous pouvez développer un script PHP exportant une base MySQL en XML par exemple. Transformer ensuite le fichier XML à l'aide d'une feuille de styles XSLT ou à l'aide d'un autre script PHP générant du XHTML/CSS par exemple... Les idées ne manquent pas.
Après si vous voulez vraiment développer un SGBD XML, rien ne vous empêche. Mais c'est réinventer la roue, mal répondre à votre besoin et sans doute hors de votre portée pour le moment car honnêtement... le développement d'un SGBD est une tâche énorme. On en voit jamais le bout, il suffit de lire un bouquin sur l'architecture d'un SGBD pour le comprendre. Si seulement il n'y avait que la concurrence à gérer :)
Newsgroups wrote:
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et
fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je
positionne le suivis plutot dans fcl.php. (avec l'espoire que ma
question y trouve sa place :-) )
Il manque le suivi sur le groupe PHP. Peut-être qu'il aurait fallu
"cross-poster" sur le groupe XML plûtôt.
Bon, je vais prochainement réaliser une base de données. Je souhaite
la faire en xml (j'ai envie ! et je suis motivé par ce choix... bref,
j'ai mes raisons). Seulement, j'ai peur qu'il y ait des concurrences
si plusieurs clients se connectent au site (et donc à la BDD).
Il ne faut pas mélanger BDD et SGBD. Le SGBD permet justement de gérer la
concurrence au sein de BDDs, entre autre chose. La BDD ne reste qu'un
ensemble organisé de données. Pour les SGBD XML voir du côté de Xindice,
Berkeley DB XML, eXist... Par contre je n'ai jamais essayé d'utiliser ces
SGBD avec PHP, en Java uniquement.
Par contre je pense que la gestion de données en PHP à l'aide d'un fichier
au format XML reste un très bon exercice pour apprendre ces sujets. Par
contre il ne faut pas considérer qu'un script PHP et un fichier XML remplace
un SGBDR comme MySQL ou SQLite. Comme solution hybride vous pouvez
développer un script PHP exportant une base MySQL en XML par exemple.
Transformer ensuite le fichier XML à l'aide d'une feuille de styles XSLT ou
à l'aide d'un autre script PHP générant du XHTML/CSS par exemple... Les
idées ne manquent pas.
Après si vous voulez vraiment développer un SGBD XML, rien ne vous empêche.
Mais c'est réinventer la roue, mal répondre à votre besoin et sans doute
hors de votre portée pour le moment car honnêtement... le développement d'un
SGBD est une tâche énorme. On en voit jamais le bout, il suffit de lire un
bouquin sur l'architecture d'un SGBD pour le comprendre. Si seulement il n'y
avait que la concurrence à gérer :)
Tout d'abord, je post à la fois dans fr.comp.applications.sgbd et fr.comp.lang.php. Je pense que les 2 groupes conviennent, mais je positionne le suivis plutot dans fcl.php. (avec l'espoire que ma question y trouve sa place :-) )
Il manque le suivi sur le groupe PHP. Peut-être qu'il aurait fallu "cross-poster" sur le groupe XML plûtôt.
Bon, je vais prochainement réaliser une base de données. Je souhaite la faire en xml (j'ai envie ! et je suis motivé par ce choix... bref, j'ai mes raisons). Seulement, j'ai peur qu'il y ait des concurrences si plusieurs clients se connectent au site (et donc à la BDD).
Il ne faut pas mélanger BDD et SGBD. Le SGBD permet justement de gérer la concurrence au sein de BDDs, entre autre chose. La BDD ne reste qu'un ensemble organisé de données. Pour les SGBD XML voir du côté de Xindice, Berkeley DB XML, eXist... Par contre je n'ai jamais essayé d'utiliser ces SGBD avec PHP, en Java uniquement.
Par contre je pense que la gestion de données en PHP à l'aide d'un fichier au format XML reste un très bon exercice pour apprendre ces sujets. Par contre il ne faut pas considérer qu'un script PHP et un fichier XML remplace un SGBDR comme MySQL ou SQLite. Comme solution hybride vous pouvez développer un script PHP exportant une base MySQL en XML par exemple. Transformer ensuite le fichier XML à l'aide d'une feuille de styles XSLT ou à l'aide d'un autre script PHP générant du XHTML/CSS par exemple... Les idées ne manquent pas.
Après si vous voulez vraiment développer un SGBD XML, rien ne vous empêche. Mais c'est réinventer la roue, mal répondre à votre besoin et sans doute hors de votre portée pour le moment car honnêtement... le développement d'un SGBD est une tâche énorme. On en voit jamais le bout, il suffit de lire un bouquin sur l'architecture d'un SGBD pour le comprendre. Si seulement il n'y avait que la concurrence à gérer :)
