Stockage de données : BDD/Fichiers/En mémoire

Stockage de données : BDD/Fichiers/En mémoire - PHP - Programmation

Marsh Posté le 11-04-2010 à 19:07:28    

Bonjour,
 
Je souhaite réaliser un site web en PHP5. Une partie de ce site serait une sorte d'encyclopédie recensant des objets (nom, description, caractéristiques ...). Il devrait y en avoir 2.000 à 3.000.
 
Ces données n'ont pas pour objectif d'être modifiées au fil du temps mais j'aurais besoin de les triés, d'en sélectionner seulement une partie selon certain critères pour les afficher ensuite.
 
J'hésite sur la façon de les stocker :
 
-> Utiliser une Base données ?
 
Cela permettrait de gérer les données d'un façon souple et d'exécuter des requêtes SQL qui me permettront de faire des tris/sélections complexes avec peu d'effort.
Par contre c'est une méthode assez lente (nécessite une connexion à la base), surtout sur des tables de plusieurs milliers de lignes.
 
-> Utiliser des Fichiers ?
 
Cela me permettrait d'éviter des connexions avec une base de données, ce qui est plutôt couteux en temps.
Par contre effectuer des tris ou des sélections selon plusieurs critères risque d'être assez difficiles à implémenter.
 
-> Stockés les données en dur dans mon script PHP et les gérer au moyen de classes ?
 
Cela me permettrait d'avoir des performances beaucoup plus importantes qu'avec les deux autres méthodes. Les données n'ayant pas besoin d'être modifiées il n'y aurait pas trop de problème.
Par contre je devrais implémenter des fonctions de tris et de sélections qui seront forcement moins optimisées que celles utilisées par une base de données. De plus j'ai peur que la présence de plusieurs milliers d'objets en mémoire par utilisateur pose un problème au niveau du serveur. Je ne suis pas sur qu'il tienne le coup. Et je finirais peut-être par y perdre niveau performance.
 
 
Que me conseillez-vous ? Si quelqu'un a déjà dû gérer une grosse masse de données lors d'un développement web, j'aimerais bien connaitre les choix qu'il a fait.
 
 
Merci d'avance.

Reply

Marsh Posté le 11-04-2010 à 19:07:28   

Reply

Marsh Posté le 11-04-2010 à 19:12:14    

base de données. C'est loin d'etre lent, surtout avec si peu de données
 
Beaucoup de données en Mysql , c'est plus de 1 000 000 de lignes . Et même comme ça, c'est gérable en jouant sur les caches

Reply

Marsh Posté le 11-04-2010 à 20:16:35    

Ok merci pour ta réponse rapide, je pense que je vais faire ca.
 
Sinon j'ai une autre question. Ma table risque d'avoir 50 champs SMALLINT qui correspondent à chaque caractéristiques de mon objet. Ne vaudrait-il pas mieux de les fusionner en un seul champs VARCHAR() avec un séparateur ?  
Par exemple avoir un seul champs VARCHAR qui contiendrait "10/5/12/15/10/3/5" plutôt que 7 champs SMALLINT qui contiendrait 10, 5, 12, 15, 10, 3, 5
 
Parce que gérer beaucoup de champs je me demande si ca va pas être nuisible au niveau performance ...
 
 
Aussi, il n'y aura aucune opération de modification ou de suppression des données sur ma table (ou alors dans de rare cas qui seront fait manuellement). Donc la quasi totalité des opérations faites sur la table seront des SELECT. N'y a-t-il pas un moteur de stockage à privilégier dans de tel cas ?


Message édité par Delta14 le 11-04-2010 à 20:33:26
Reply

Marsh Posté le 11-04-2010 à 20:43:22    

non
imagine quand tu vas chercher la valeur du 14eme champ, le nombre d'opérations nécessaires
 
et honnetement, tu n'aura pas un volume de données qui mettra a génoux un sgbd correct ( postgresql, ou même mysql)

Reply

Marsh Posté le 11-04-2010 à 21:17:29    

Ok merci pour tout ! Je vais pouvoir me faire ma base de données ^^

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed