Discussion :

[islogged]

Bonjour,

Je me pose la question, de la pertinence d'une base de données confronté à un système de fichier classique.

Pour cela imaginons un site classique utilisant déjà la technologie php pour sa conception.

Imaginons que je n'ai pas besoin de tout un System de gestion de base données, mais juste un fichier php (pourquoi pas) de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
//couleur.php
<?php
 
bleu ocean
jaune soleil
vert plante
rouge sang
etc ...
 
?>

Et que associer à mon site (toujours), j'ai une fonction qui en recherchant "recherche(vert)" me retourne "plante".

Je voulais savoir, si coté serveur cela serait plus lourd (niveau charge) a utiliser un tel système plutôt qu'une base de données classique (mysql ou autre).

Merci

[stealth35]

si le système est aussi simple que ça, garde un fichier php
si c'est plus compliquer et que t'as 50000 entrée faudra penser a passe sur un SGDB

[gene69]

tout depends de la longueur de la liste et de son utilisation.
tant que tu restes sur une courte liste statique, la coder en "dur" c'est simple et économique. dès que tu auras une grande liste dynamique alors une base de donnée sera plus pratique.

ya un côté "spychologique" à la définition d'une grande liste cependant. PHP gère extremement bien des tableaux avec des miliers d'entrées.

[islogged]

Merci pour vos réponses rapide.

Effectivement dans mon cas, je n'aurai pas plus de 1000 entrées.

Vos réponses vont aussi dans le même sens que je pensais.

Il n'y pas lieu de ce surcharger d'une technologie s'il n'y en a pas besoin.

Donc dans mon cas précis, j'ai donc ma réponse !

Mais d'un point de vue plus intellectuelle, je me demandais puisque l'exemple à ét é donné, si j'avais 60 000 entrées une recherche en base de données serait elle vraiment plus rapide, qu'une recherche au sein d'un fichier ?

Parce que j'imagine, que quelque part une base de données c'est aussi un fichier non ?

Voila, merci

[stealth35]

c'est pas un problème de place, mais de processeur et de mémoire

[ericd69]

c'est pas que ça le problème...

tu as aussi des problèmes d'algorithmique... l'implémentation en mémoire des tableau php n'est pas celle des tables mysql du tout... php est généraliste alors qu'un sgbd lui va être optimisé pour ça...

dans une bd une table c'est plusieurs fichiers mais tu as un système de cache mémoire et d'optimisation pour les requêtes et les données... tu ne relis pas les fichiers de données forcément...

php n'est pas du tout pensé pour ce que tu veux faire vu que tu ne peux pas garder en mémoire ton tableau... donc si tu as peu de recherches comme ça pas de soucis, si tu as une certaine quantité de connexion à ton script et en fonction des réglages pour les ressources de ton hébergement... c'est plus vrai...

en fait, c'est un tout et y a pas de réponse garantie à par tester réellement...

donc à chaque recherche:

• tu recharges ton fichier (selon la méthode choisie ça peut vite plomber les performances)
• tu recrées le tableau
• tu refais la recherche

les 2 premiers points sont les plus gourmands en ressources
donc à réfléchir

[grunk]

Mais d'un point de vue plus intellectuelle, je me demandais puisque l'exemple à ét é donné, si j'avais 60 000 entrées une recherche en base de données serait elle vraiment plus rapide, qu'une recherche au sein d'un fichier ?

Plus que le nombre d'entrée , c'est surtout l'utilisation que tu vas en faire. Comme le précise ericd69 il y'a plein de paramètres à prendre en compte.

Sur une base de données il est très simple par exemple de trouver tous les utilisateur inscrit avant tel date.
C'est possible aussi avec un simple fichier mais tu vas devoir parcourir tous le fichier , parser chaque ligne pour trouver la date ...
Le SGBD lui aura des colonnes indexées, du cache en mémoire qui vont le rendre très rapide.

Dans le même esprit que va t'il se passer si 2 utilisateurs on besoin d'ecrire en même temps dans ton fichier ? Le SGBD lui sais gérer les accès concurrent sans tout casser

A mon avis dès que le besoin dépasse la simple lecture de clé/valeur le sgbd peut se justifier.