bonsoir,j'ai la possibilité de mettre en ligne un site qui fonctionne sans Bdd Msql.
il s'agit d'un site de petites annonces(j'en possède déjà 3 qui sont propulsé par xoops),mais celui ci m'intrigue et je me pose la question:quel avantage et quel inconvénient d'avoir un site sans BDD?
merci de votre avis
cordialement

Moi la question que je me poserais plutot est : comment fait-il pour gérer correctement ses petites annonces avec des fichiers ?

Si sa gestion est très bonne, il gagne potentiellement à ne pas se connecter à un serveur de bdd. Parallèlement, il réinvente peut-être le métier de SGBD(R) si bien géré par ces derniers, et de leurs capacités à garder des infos en RAM et j'en passe.

Je ne vois pas pourquoi un site devrait absolument avoir une base de données, ni à ne pas en avoir. Peut-être peux-tu regarder comment lui gère ça.

Bonjour merci pour ton avis il intéressant! Je ne vois pas comment il gère les utilisateurs et les annonces sans base de données!malgré cela j'ai appris quelque chose intéressante.merci

Yop,

y a pas mal de chose qui fonctionne comme ça (je suis tombé sur pluxml par exemple).

c'est tous a fait utilisable s'il n'y a pas trop d'accès je pense (trop d'accès disque pb de lock sur les fichier etc).

comme indiqué avant "ça dépend" de l'utilisation et de la fréquence d'utilisation, par exemple en lecture avec un cache pas trop de soucis, en écriture c'est un peux plus gênant


@+

merci

Tu parles d'accès disque avec puxml, mais dans selon la configuration du SGBDR que du utilises, chaque requête va générer un ou plusieurs accès au disque.
Donc l'un dans l'autre, ca revient au même.
Le seul désavantage que je dois a ces méthodes dans l'immédiat est que les grosses bases de données ne peuvent être chargées de cette manière, car on va dépasser la mémoire allouée.

l'intérêt des sgbd c'est d'une part les features que peut avoir un sgbd et qui facilite l'exploitation, et d'autre part la gestion des accès concurrents (lecture + écriture de la même donnée), 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, c'est à dire que si un sgbd est fait en c, c'est plus rapide d'aller lire/écrire des fichiers en c, maintenant pour comparer un langage comme php qui a plusieurs facteurs de ralentissements vis à vis d'un binaire, c'est assez difficile sans faire de benchmarks précis dans des conditions choisies (données, taille des données, nombre d'accès etc)

pour synthétiser, les deux se valent à mon avis, seulement interagir avec un filesystem est plus compliqué de gestion, donc je donnerais un avantage aux bases de données pour une application qui gère vraiment des données (comme un site de petites annonces) et un avantage à l'absence de base de donnée pour les choses plus simples (exemple bateau un compteur de visite, un système d'authentification à la limite aussi)

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. Pour un système complet et évolutif de gestion de petites annonces un unique système de fichiers ne me semble pas adapté. Mais bon pour des besoins limités en recherche et en administration... pourquoi pas. Perso je serais assez réticent si je considère le potentiel d'évolution d'un tel système.

Sinon j'utilise parfois les fichiers pour des besoins similaires à ce que Nagol décrit.

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,

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

tu peux très bien faire des site pseudo dynamique, ça marche très bien, et récupérer du contenu uniquement via javascript, y'a aussi des petits générateurs comme jekyll

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,

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

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

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

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

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

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

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