Bonjour !

Afin d´approfondir mes notions en POO, j´ai décidé de me lancé dans un projet libre qui constitera à développer un blog (peut etre un peu plus qu´un simple blog).
J´ai dans l´intention de bannir mysql du script. Par contre, j´insisterai dans sur la gestion des données via des fichiers xml et c´est là que j´ai beosin de vos avis : les articles et commentaires seront donc enregistrer dans des fichiers sous forme de données xml mais pensez vous qu´il soit mieu que :
1 article = un fichier xml
ou les articles = un fichier xml ? (idem pour les commentaires).

Par ailleur, mon script se voudra légé.

Merci

Certains hébergeur, dont 1and1 limite le nombre de fichiers sur leur hébergement, même si plus de 200 000 fichiers sont autorisés

Je pense que, un fichier xml pour l´article, et un pour les commentaires qui y sont rattacher ca peut-être bien quand pensez-vous ?

PostGreSQL powaa

là ça peut etre pas mal

(j´ai hate de faire joujou avec les Execption )

ah zut posté avant que je puisse lire le post de Darth-Bane xD PostGreSQL c´est cool quand tu as un nombre important de données, sinon msqyl vaut mieux

Bon pour être sérieux 2 minutes, utiliser des fichiers dans certains cas peut être bénéfique et plus adapté qu´une BDD, mais passer en "tout fichier", je ne pense sérieusement pas que ça soit une réelle amélioration, bien au contraire même.
Il faut utiliser ce qui est le plus adapté.

Le seul intérêt que je vois au "tout fichier", c´est le challenge technique, c´est tout.

MySQL étant parfois un peu lent, et limité en nombre de requêtes simultanées, PostGreSQL peut être une très bonne alternative. DE plus, il comporte un certain nombre de fonction interressantes que ne possède pas MySQL.

Sinon, pour répondre à ta question :
"es articles et commentaires seront donc enregistrer dans des fichiers sous forme de données xml mais pensez vous qu´il soit mieu que :
1 article = un fichier xml
ou les articles = un fichier xml ? (idem pour les commentaires)."

un fichiers pour TOUS les articles, sinon, ça n´a aucun intérêt, un simple fichier txt suffit.
L´avantage du XML c´est que tu peux filtrer le XML grâce au XSLT.

sauf que la gestion de postgresql sur un petit nombre de données n´est pas rapide (leur alogo n´est pas adpaté) alors que mysql oui (effet inverse en ce qui concerne la gestion de grand nombre de données).
C´est surtout pour aller plus loins dans la POO avec php 5.
Ceci dit, j´ai (comme je l´ai deja dis) utilisé des fichiers pour séries-sources et la seul mauvais surprise que j´ai eu, c´est le coup de monsieur pas de bol du fichier de stats supprimé.
L´avantage d´un tel script serait sa portabilité (copie/collé entr ftp et ça fonctionne) en imaginant que les version de php soit les meme.

je viens de penser à une chose : si je stock tous les articles dans un seul fichier, j´aurai un fichier très gros au bout d´un certain temps....on pourrait imaginer que avant l´ajout d´un données, on test si le fichier n´est pas trop saturé et dans le cas contraire, un nouveau fichier est créé

Avec une faible quantité de données, mais un grand nombre de connexions simultanées, PostGreSQL reprend l´avantage, il me semble

Bah s´il souhaite la portabilité (car projet libre), autant prendre MySQL car il est beaucoup plus utilisé par les utilisateurs "novices" que PostGreSQL.

Mais l´utilisation de fichiers XML ça peut être pas mal

J´pencherai plus vers une condition qui vérifie la taille du fichier et si elle dépasse ou s´approche du seuil maxi, on créé un new fichier.

deepblue, le coup d´un fichier unique, sa ralentirai tous, j´ai la cas au taf, on a des fichier excel sur serveur, au bout de deux semaines, 5 minutes par enregistrement, c´est pareil si le fichier est trop gros ... je pense qu´un fichier jour peut-être

Excel pour gérer de données

Sérieux, c´est normal que ça rame, ça n´est pas, mais alors pas du tout adapté ! Il faut comparer ce qui est comparable !

L´utilisation d´XML peut être très rapide si c´est bien géré.

K-L-3-Z > je pensais à ça
Darth-Bane > j´en connais que trop peu pour te titiller plus
"L´utilisation d´XML peut être très rapide si c´est bien géré." d´ou mon pic

Thymos > pourquoi pas mais l´idée du "si fichier trop gros, nouveau fichier" me tente plus

"Bah s´il souhaite la portabilité (car projet libre), autant prendre MySQL car il est beaucoup plus utilisé par les utilisateurs "novices" que PostGreSQL"

Ce ne sont pas les utilisateurs qui travaillerons sur la BDD, il me semble, non
Enfin, moi je vois plus un accès au données via une interface.

deepblue pas obligatoirement évident à gérer plusieurs fichiers xml pour gérer le même type de données.
Et puis si tu en arrive à obtenir un trop gros fichier, c´est que l´utilisation d´un moteur de BDD est bien plus adapté.

"Ce ne sont pas les utilisateurs qui travaillerons sur la BDD, il me semble, non"

Je pensais que le projet serait distribué sur le net pour que chacun puisse l´installer, à l´instar d´un DotClear ou autre

Parmis les hébergeurs gratuits, c´est vrai qu´il y´en a peu qui intègre PostGreSQL, je l´avoue.

Darth, c´est pratique, si tu veux tu as une classeur par pièce fabriquer, tous le relais tu crée une feuille ou tu rempli les info de la commande, la machine qui fait la pièce, la référence matière et colorant et divers infos, tu indique les controle fait sur les pieces, poids, tailles, aspect ... tu indique les éventuelles problèmes, tu indique les cartons de pièces que tu as fermer, donc ca grimpe vite, ce n´est pas le fait d´utiliser excel, mais plutôt de stocker a distance, il sauvegarde tous les deux mois, quand je suis arriver, c´étais au moins 5 min sur les pièces qui sont fabriquer en permanence

Le pb, c´est que pour chaque cellule, utilisée ou pas, une place est réservée pour définir les paramètres, les macros, ... ce qui prends de la place. Regarde déjà la place que prends un fichier vide.
Et puis pour l´utilisation en simultané par plusieurs personnes, tu repasseras.
En plus, celà oblige à avoir une license par poste où le fichier est utilisé.
Pour peu que ton parc de PC ne soit pas homogène, les versions d´excel ne le sont pas obligatoirement non plus et parfois, la compatibilité du fichier en prends un sacré coups.