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.

[islogged]

Ok !

Dans mon cas précis, je ne n'aurai pas plus de 1000 entrées, ma recherche se fera uniquement sur des entrées de type 'chaine de caractères' et qui de plus est en lecture seule (donc comme dans mon exemple).

Donc dans mon cas, pour l'instant le fichier .php reste préconisé !

Par contre une autre question que je me pose, donc :
- Outre le nombre d'entrées
- Outre le type de recherche
- Outre le type d'accès

Si j'ai 100 000 personnes qui font une recherche (donc accède en même temps à mon fichier php qui possède la liste), je suppose qu'une base sql étant plus adapté restera moins lourde et donc plus rapide sur le serveur.

Mais dans mon cas précis :
- Recherche parmi 1000 entrées de type Chaine en lecture seule par 100 000 utilisateurs simultanées.

Est-ce "qu'a vu de nez" utiliser une recherche au sein d'une liste stocker dans un fichier .php (même si moins efficace qu'une recherche sur une base de données classique) reste crédible ?

Merci

Merci

[ericd69]

teste y a que ça...

faut te dire que si tu as un index texte dans un tableau certains caractères sont automatiquement changés en _ ce qui peut poser des problèmes de doublon ou de mises en commun (ou de remplacement et donc de disparition) de certaines valeurs...
donc à bien faire gaffe

faut pas voir ça toujours avec un regard trop simple

une bonne façon de bien gérer ces risques c'est de stocké les différentes valeur sur le 2ème niveau:
$tab[x][0] la valeur de recherche
$tab[x][1] la valeur à donner
avec x le numéro de ligne dans le tableau $tab
mais c'est beucoup moins performant vu que tu dois faire un boucle de lecture et que tu ne peux pas utiliser directement les fonction de parcours plus optimisées

bref, testes y a que ça pour savoir quelle implémentation sera la mieux
mais sachant que de base, tu as mysql sur tout hébergement mutualisé, je pense que tu te fais des nœuds au cerveau pour rien

[Djakisback]

Salut,
je ne peux pas répondre à ta question mais je pense que tu aurais intérêt à définir directement un tableau PHP dans un fichier que tu includes plutôt que d'ouvrir ton fichier à chaque fois. ex :

Code :

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

1
2
3
4
5
couleur.php
<?php
$couleurs['bleu'] = 'ocean';
etc ...
?>

Je ne sais pas si PHP met en cache ce type de variable, si quelqu'un le sait, cela m'intéresse aussi mais même si elles ne sont pas mises en cache, je dirais que c'est moins problématique que de créer 100 000 pointeurs sur le même fichier mais bon c'est plutôt une intuition (d'un autre côté le handle en lecture seule est peut-être partagé lui-aussi... en tout cas ça évite la recherche)

[edit] Ok, merci ericd69[/edit]

[ericd69]

y a pas de cache php

ça sera réinterprété à chaque fois...

[CinePhil]

Soit 1000 entrées dans ton tableau et 100 000 utilisateurs qui l'utilisent à peu près en même temps.

1) Tout en PHP
Chaque utilisateur va entraîner un chargement du fichier contenant le tableau à partir du disque, soit 100 000 accès disques.
Le programme PHP va parcourir le tableau 100 000 fois pour chercher les valeurs dont chaque utilisateur a besoin.

À chaque fois que chaque utilisateur aura besoin de ce tableau, ce sera idem.

Demander l'utilisation de la table va donc entraîner un flux de 1000 entrées * quelques octets à quelques dizaines d'octets à chaque fois, donc plusieurs dizaines à plusieurs centaines de ko à chaque utilisation.

2) En PHP + SGBD
À supposer que toutes les données du tableau soient sémantiquement cohérentes, tu auras une table de 1000 lignes de données. Au vu de ce que tu présentes, les données ne sont pas grosses et la table non plus. Elle aura au moins un index de clé primaire + un à plusieurs index sur les différentes colonnes de la table.

le premier utilisateur demander l'utilisation de la table va entraîner le chargement en mémoire de l'index de clé primaire et d'un à plusieurs index sur les colonnes signifiantes puis d'un morceau ou de toute la table.

Pour les 99 999 autres, tout ça sera déjà en mémoire et il n'y aura plus d'accès disque. L'interrogation d'une petite table indexée par un SGBD se fait en une fraction de seconde et retourne juste le résultat nécessaire.

Chaque interrogation de la table va entraîner, entre le logiciel applicatif et le SGBD :
- l'envoi d'une requête SQL, c'est à dire un texte de quelques dizaines ou centaines d'octets ;
- le renvoi par le SGBD vers le logiciel applicatif de la réponse nécessaire à l'utilisateur et pas de toute la table. Si l'utilisateur n'a besoin que d'une ligne de la table, ça ne représente au plus que quelques dizaines d'octets.

L'aller-retour ne représentera la plupart du temps qu'une centaine d'octet au plus.

Qu'est-ce qui est le plus efficace à ton avis ?