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

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

Sans BDD un système de recherche ne peut pas être très performant, ou tout au moins il sera limité à certaines recherches précises et prédéfinies mais peu évolutif.

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...

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

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 ...

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

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

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.

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.

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 ?

@+

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)

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.