Ouais, l'avantage de ne pas utiliser une bdd, c'est de ne pas avoir besoin d'utiliser un moteur externe pour rapatrier des données.

Celui-ci étant spécifiquement conçu pour accélérer des recherches croisées, on peut donc s'en passer pour des données "basiques", mais un système de fichiers texte "simples" se limite à ce simple usage.

Pour le reste j'imagine mal comment on pourrait remplacer une bdd par des fichiers texte à parser, tant en termes de fonctionnalités, d'évolutivité, qu'en termes de performances, où alors comme dit plus haut cela revient à réinventer un moteur de bdd.

Pour avoir tenté de monter un SGBD à partir d'une structure XML je suis aussi intéressé par ces soit disant performances. ^^
Rien que l'ouverture du fichier mets souvent autant de temps qu'une requête basique de sélection... (et ouverture sans cache du contenu je parle, lecture en streaming)

Les bench ça pourrais être intéressant.

Ceci dit comparer un système XML + php avec et un sgbd je trouve ça un peu étonnant rien du fait des performance indiqué par zeus mais aussi des fonctionnalités rien que les contraintes des clefs étrangères et les contraintes check c'est pas une mince affaire et si tu les implementes ben tu aura commencé à faire un sgbd ;)

Dans le cadre d'une petite structure type blog pourquoi pas mais je ne suis pas certain sur de grosses.

Par exemple pour un forum tu remet le nom des gens qui répondent à chaque fois ?
Ça fait des sources des erreurs des données en trop qui alourdissent le fichier.
Si tu met l'id tu parse d'abord un fichier de membre que tu met en mémoire et ensuite tu l'utilise pour l'affichage ?

Géré tu l'accès concurrent ?
Un flock ?
Que ce passe il en cas de montée en charge ?

@+

J'aimerais que tu nous montres tes benchs, histoire de voir comment tu t'y prends.

Sinon, mon avis sur la question de base et que ça dépend du site, des données à stocker, ...
Ne pas oublier qu'un SGBD, c'est un moteur qui stocke des données dans des fichiers, au final. Sauf qu'il est très performant pour accéder à ses données.
Il le sera quasiment toujours plus qu'un code PHP qui lit les données d'un fichier (quelque soit son format) car il est optimisé pour le faire.

Je pense que si on prenait un schéma de données avec quelques types d'entités, et des liaisons entre (disons un forum, avec des membres, des messages et des catégories), on verrait que le SGBD est très rapidement plus rapide qu'un système qui va parser du XML et croiser les données à la main.

Et bien par exemple on prend 2 scripts: 1 qui se connecte a une base de donnée et un autre qui récupére des infos dans des fichiers XML et on observe que le 2ème script est légèrement plus rapide.

Sur quelles bases juges-tu que tu gagnes du temps ?

Personnellement je développe mon site en 100% xml donc sans aucune BDD et cela reste très organisé et clair et en plus je gagne un temps non négligeable par rapport à des sites avec BDD

Oula, tout un début. Mais serions-nous en train de réinventer la roue, ou de dire que les inventeurs des SGBD sont des idiots qui n'avaient que ça à faire ?

Allons-nous réellement parler des performances entre des fichiers et des SGBDR alors que nous développons des applications qui à elles seules lisent une dizaine de fichiers avec des centaines de lignes de classes dedans, qui doivent être reparsées à chaque page appelée ?

Devons-nous comparer un SGBDR alors que le système de vérouillage des fichiers avec PHP est vraiment ... fouareux ? J'ai essayé personnellement, et vraiment, ce n'était pas un succès !

Combien de temps allez-vous mettre pour développer un système fiable qui ne fera ne serait-ce qu'enregistrer des champs, en sachant les délimiters et échapper les données entrantes pour qu'elles n'entrent pas en conflit avec les délimiteurs, et pouvoir lire les données du fichier sans l'importer entièrement dans une variable pour ne pas saturer la RAM sur un gros fichier ? Allez-vous vraiment essayer de concurrencer des SGBDR sur lesquels des milliers de personnes ont travaillé et qui existent depuis au moins les années 70 ?

Franchement, je suis peut-être fermé comme mec, quand j'avais 11 ans je m'amusais à faire du parsage de fichiers en y stockant des valeurs à la manière d'un .ini ... mais maintenant, je fais PDO::__construct(), PDO::query(), PDO::fetchAll, et j'ai rien d'autres à faire même pour un site aussi bête que le mien qui pourtant ne possède que 10 pages à tout casser sans catégories, avec juste un titre, une url ... Mais même pour ça, j'ai préféré la bdd ...

:non: :priere:

[quote="macgawel"][quote="AB"][b]Sans BDD un système de recherche ne peut pas être très performant[/b], ou tout au moins il sera limité à certaines recherches précises et prédéfinies mais peu évolutif.[/quote]Ca dépend comment c'est géré...
Si tu as tes annonces dans un unique fichier, tu peux utiliser les expressions régulières. Et au niveau puissance/rapidité/possibilités, ça tient largement la comparaison...[/quote]

C'est la deuxième partie de la phrase qu'il fallait retenir ou tout au moins la phrase entière :wink:
Quand le parle de système évolutif je ne parle pas en termes de quantité, mais plutôt fonctionnalités.

je vois pas le rapport, c'est en comparaison avec les regex pour un outils de recherche, je parle pas du reste

Hum... oui, enfin Lucene au final, c'est pas vraiment ce que j'appelle se reposer sur le SF. Parce que bon, si on y va par là, MySQL aussi repose sur le SF...

Et si on ne veux qu'un seul fichier, et pas de serveur de base de données, on peut aussi passer par sqlite, comme ca on fait du SQL, mais on a pas de serveur.

Et si le problème c'est le SQL, dans ce cas on peut aussi faire du NoSQL :-)

[quote="macgawel"]Si tu as tes annonces dans un unique fichier, tu peux utiliser les expressions régulières. Et au niveau puissance/rapidité/possibilités, ça tient largement la comparaison...[/quote]

je dirais plutôt des systèmes comme [i]Lucene[/i] qui te crée des indexes

[quote="AB"][b]Sans BDD un système de recherche ne peut pas être très performant[/b], ou tout au moins il sera limité à certaines recherches précises et prédéfinies mais peu évolutif.[/quote]Ca dépend comment c'est géré...
Si tu as tes annonces dans un unique fichier, tu peux utiliser les expressions régulières. Et au niveau puissance/rapidité/possibilités, ça tient largement la comparaison...

Pour ma part, je dirais que le SGBD est plus performant en cas de :
- Accès concurrentiels (plusieurs utilisateurs peuvent créer/modifier/supprimer des items).
- Liaisons fortes entre les données.
- Gros volumes.

Le système par fichier(s) est plus adapté sur des petits volumes et/ou des mise à jour peu nombreuses (puisque dans ce cas on va passer par le cache) surtout si le gestionnaire final du site n'a pas les connaissances requises en SQL...

Pour suivre la voie de la simplicité, j'ai souvent commencé à utiliser les fichiers comme moyen de stockage sur certain site, mais au fur et à mesure des besoins, j'ai quasiment toujours été obligé de finalement tous mettre en base de données.

Sur l'exemple des petites annonces, viendras forcément le jour où :
- il faudra qu'un utilisateur puisse voir toutes ces petites annonces
- un moteur de recherche devra être intégré
- les annonces vont avoir des tags
- etc...

Dans quasiment tous ces cas, je pense que l'utilisation de fichier est une hérésie. On est obligé dé :
- maintenir un fichier avec le nombre d'annonce par utilisateur => alors qu'un index fait exactement ca
- maintenir un fichier avec les associassions mot-annonce, en pensant à stemmer les mots => un index full text
- etc ...

Bref, on réinvente la base de données dans le programme... Ce n'est pas mal en soit si on pense pouvoir faire mieux que les développeur de BDD, mais dans ce cas, je demande à voir...

[quote="epommate2"][quote="Nagol"] le désavantage d'un sgbd c'est les performances, il est systématiquement plus rapide d'accéder directement aux fichiers à langage de programmation équivalent,[/quote]

Alors là, je trouve que tu t'avance beaucoup....

Si par exemple tu a beaucoup d'annonce (>1G), je ne suis pas très sur que si elles se trouvent toutes dans le même répertoire, la sélection d'une annonce sera aussi rapide avec le FS qu'avec une BDD (mais bon, je ne suis pas sûr du contraire non plus).[/quote]

c'est pourtant vrai, un sgbd n'est qu'un système de mise à disposition en ram d'un fichier avec une api pour récupérer les informations d'une certaine manière (le sql), quand tu lit un fichier avec un fopen en c, tu fais ce que fait un sgbd, sans les fioritures :)

un sgbd n'est pas la pour être performant vis à vis d'un filesystem, il est la pour faciliter l'exploitation, un peu comme un framework objet n'est pas la pour la performance mais pour faciliter l'exploitation du code, je sais que beaucoup de développeurs considèrent que l'utilisation d'un sgbd ou d'un framework est une façon de faire les choses qui augmente la performance et la scalabilité de leur code, mais en vérité ils augmentent leur propre confort plutôt que la performance brutte de ce qu'ils codent, comme je dis souvent réinventer la roue c'est une attitude saine :)