Bases de données pour quoi faire

[stever34]

Salut je continue ma petite formation PHP / MySQL avec mon livre de mricroapp

Et n'étant pas dans le milieux de l'informatique je voulais savoir s'il était possible de m'expliquer avec des cas concret ce qu'il est possible de faire avec les BD

Car pour ce qui est des forum, blog et e-commerce je comprend

Mais existe t il d'autre domaines (exemples) d'utilisation.

car n'ayant qu'une vision extérieure au monde de l'info et ll'utilisation des BD étant indétectable sur un nivigateur, j'ai pas idée des possibilité que cela offre ?

[robinsonvendredi]

Mais existe t il d'autre domaines (exemples) d'utilisation.

La grande majorité des applications pour le web utilise une base de données.

Les cas où une bdd n'est pas utile sont rares :

- petit site web développé et maintenu par la même personne,

- système de fichiers XML se substituant à un SGBDR.

Donc seulement 2 cas de figure à ma connaissance.

[c.klouchi]

Si tu as compris le but et le fonctionnement d'un Blog tu as tout compris.

La BDD strocke tous types de données ... fichiers clients, hotel .... Seul ton imagination t'arrête !

L'avantage et de pouvoir interroger la BDD par des requêtes SQL et manipuler, faire ressortir les reusltats à ta convenance.

Exemple

Les client de plus de 30 ans

Les hotels de Fréjus

etc ...

Ensuite, il y a egalement le partage de l'information comme stipulé plus haut (je vois) à savoit partager sous forme de RSS et XML et esporter dans différents formats.

Modifié 23 Août 2006 par c.klouchi

[rportal]

Une base de données te permet de stocker, trier, traiter, automatiser, transformer,... des données. Donc les cas d'utilisation sont innombrables.

Si tu prends par exemple le domaine des sondages/statisques, derrière tu as des bases de données. L'intelligence économique, idem. Le calcul scientifique pour rechercher les petits hommes verts, idem. Les réseaux télécoms utilisent aussi des bases de données...

Il faut voir un site web comme un simple client à ces bases. Du coup un site web te permet de manipuler les données des bases avec lesquelles il est interfacé.

[stever34]

Oui quand on a des masses d'informations a croiser, mais pour des sites plus statiques

avec du texte et des photo de présentation

page accueil -> accueil.php

page présentation -> presentation.php

page contact -> contact.php

y a t il un intéret a a voir une page index.php qui charge les variables $accueil, $presentation ou $contact

Pour des info qui ne se croisent pas en foncion de critèresmais plutot des présentation style article.

Y a t il avantage par rapport a un page avec du texte brut et juste des includes pour les haut et bas de pages

[xpatval]

Un exemple ?

Prenons le cas d'un site de photos. X photos pour Y thèmes.

Via un menu de gestion de la base (insertion, modification, suppression, affichage), les différents thèmes seront enregistrés dans une table.

Les chemins des photos le seront aussi dans une autre.

Le lien entre les deux tables (x photos pour UN thème) se fait grâce à ce que l'on appelle une jointure.

Dans le site de présentation des photos, tu donnes la possibilité de les visualiser par thème, ou dans leur ensemble, ce qui te permet de ne créer que peu de pages.

Sans base, il t'en faudrait 10,20 fois plus.

xpatval

[rportal]

tu peux avoir un avantage à utiliser une base de données pour des petits sites : un moteur de recherche interne.

Si ton site contient seulement quelques pages bien définies et statiques et qu'il n'est pas prévu que cela change avant un bout de temps, une base de données n'est pas nécessaire, tu fais les modifs sur ton PC et tu mets ensuite à jour ton site.

Si tu veux un site un peu plus interactif (commentaires, notation, etc), une base de données te simplifiera la vie.

[stever34]

Je vais prendre des exemple extreme dans l'autre sens pour caricaturer

http://m.cplombier.neuf.fr/

Y aurait il un avantage a faire ce site avec BD

Je rappelle que c'est une caricature extreme

mais c'est pour voir si meme sur des sites simple il peut y a voir un avantage

Bon ce site est vraiment trop simple imaginons tout d ememe un site qui a une 20ene de pages dites statiques

La BD a elle un intéret pour gérer les textes plus facilement ???

[rportal]

Quel est ton sentiment personnel sur l'utilisation ou non d'une base de données dans les cas que tu imagines. Si tu parles d'un site statique, il n'y a pas d'intérêt, si tu parles d'un site dynamique il peut y avoir un intérêt. Mais il faut aussi prendre en compte l'évolution potentiel du site, les habitudes (et envies) de celui qui mettra en place le site, etc.

pour le site du plombier, on pourrait imaginer une section "recommendations" où les clients contents postent un message pour dire combien le plombier est performant...Dans ce cas un BDD pourrait être utile

Modifié 23 Août 2006 par rportal

[destroyedlolo]

Salut,

Oui quand on a des masses d'informations a croiser, mais pour des sites plus statiques

avec du texte et des photo de présentation

page accueil -> accueil.php

page présentation -> presentation.php

page contact -> contact.php

y a t il un intéret a a voir une page index.php qui charge les variables $accueil, $presentation ou $contact

Pour des info qui ne se croisent pas en foncion de critèresmais plutot des présentation style article.

Perso, je pense que l'utilisation des BD dans les sites web est beaucoup beaucoup trop generalise

Comme tu le dis, y'a pleins cas ou ce n'est pas justifie ou ca penalise trop les perfs sans vrais valeurs ajoutees.

A titre d'exemple, je suis en train de developpe un site pour gerer de maniere completement automatique les albums de photos de mariages (pas uniquement les photos, mais aussi les textes, ... bref, ca donnera des pages completes et pas uniquement un slide show). Bref, je n'ai pas utilise de BD mais plutot des fichiers a plat qui sont mis en forme dynamiquement par des Actions Apache. C'est nettement plus flexible et surtout nettement moins consomateurs en ressources.

J'utilise uniquement des BD lorsque j'ai a faire des tries, des recherches ou a manipuler des chiffres (par exemple pour le stats), mais jamais au grand jamais pour stocker directement mes pages HTML ou des photos.

Si on prend l'exemple des photos, si je dois faire des tries ou des selections, je cree dans la base des objets qui contiennent les caracteristiques de la photos, et son URL, mais c'est tout.

C'est pourquoi, mes sites fonctionnent sur des vieux tromblons (par exemple, mon site tourne sur une vielle SUN Server5 a 110 Mhz avec seulement 128 Mo, et au taf, c'est sur une HP712 a 80 Mhz) et les temps de reponse sont plus que satisfaisant et la charge CPU negligeable mais lorsqu'il y a affluence.

Lolo

[stever34]

disons que je me demande si juste le PHP + des fichier texte ne font pas l'affaire

pacontre une BD me semble plus transportable mieux gérable

en gros ce qui me bloque c'est que si je passe en BD je vais tout passer en BD aussi bien le dynamique que le statique

les requettes de la BD ne sont elles pas lourde a gérer au niveau du serveur

N'était pas abérant pour afficher une page statique "ghgqhg dqsgjhdqibqd qsdghqdbquqhbqsuy" d'avoir a charger une variable.

Il parait que les fichiers a plat ne sont pas efficaces si plusieurs personnes se connecte en meme temps

ou que quelqu'un consulte un fichier pendant que l'autre est entrain d'ecrire dedans ?

[destroyedlolo]

disons que je me demande si juste le PHP + des fichier texte ne font pas l'affaire

pacontre une BD me semble plus transportable mieux gérable

Ben, le gros avantage est que si ton datamodel est bien foutu, il est plus facile en cas de probleme de reconstruire les liens entre objets qui aurraient pu etre perdu.

Au niveau de la portabilite, je pense que tout les hebergeurs permettent de creer des fichiers/repertoire dans ton propre espace non ?

en gros ce qui me bloque c'est que si je passe en BD je vais tout passer en BD aussi bien le dynamique que le statique

Je ne vois pas pourquoi. C'est toi qui fait le design, tu peux tres bien ne stoquer que des references dans ta BD et mettre tout ce qui est statique sur disque.

les requettes de la BD ne sont elles pas lourde a gérer au niveau du serveur

Y'a pas photo, c'est le cas de le dire. C'est encore pire lorsque tu commences a y stoquer des BLOB comme les images ou les videos.

Il parait que les fichiers a plat ne sont pas efficaces si plusieurs personnes se connecte en meme temps

ou que quelqu'un consulte un fichier pendant que l'autre est entrain d'ecrire dedans ?

Il n'y a que pour les mise a jour que le probleme se pause, mais ce n'est a nouveau qu'un probleme de design, mais il est tres facile aussi de faire un mechanisme de "COMMIT" avec des fichiers a plat. Et si plusieurs personnes souhaites mettre a jour une page en BD, les memes questions se pauseront.

[stever34]

Bon je vois que tout n'est pas tout rose et ques les avis sont tres partagés.

Mais c'est intérressant que chaqu'un expose ses points de vues c'est tres enrichissant

[Portekoi]

Bonjour,

Je ne suis pas du tout d'accord avec ce qui a été dis. Préféré les fichiers à une BDD, c'est préféré une 2CV à une BMW.

1 - L'intérêt d'une BDD réside dans sa maniabilité, sa facilité à trouver les infos et l'éventail de sécurité qu'elle propose.

2 - Une requête n'est pas lourde en soit. Maintenant, si tu as une table avec 1 000 000 d'enregistrements, que tu la croises avec une table qui en a tout autant, alors là oui, ca deviens lourd et encore que tout dépend de la création de tes clés et index. Mais avec un fichier texte, impossible de le gérer.

3 - La mise à jour des fichiers est totalement différentes d'une mise à jour en BDD : Pour un fichier, un problème de droit en écriture se pose si 2 personnes agissent en même temps. Autrement dis, l'un des deux sera jetté. Avec une BDD, si les 2 requêtes arrivent en même temps, l'une passera avant l'autre sans blocage aucun.

Très franchement, si tu as un site "basique" réaliser à l'occasion de l'anniversaire de ton oncle et que tu veux compter le nombre de visiteur, alors oui prend un fichier. Pour le reste, c'est BDD.

Pour finir, ceux qui stock des images ou autre dans un BDD pourrait très bien stocker le nom et le chemin d'accès. Mais ca, c'est une autre histoire.

Portekoi

[destroyedlolo]

Je ne suis pas du tout d'accord avec ce qui a été dis. Préféré les fichiers à une BDD, c'est préféré une 2CV à une BMW.

Ben pour reste dans les metaphore, utiliser systematiquement un BD, c'est souvent utiliser un marteau pneumatique pour enfoncer une punaise.

1 - L'intérêt d'une BDD réside dans sa maniabilité, sa facilité à trouver les infos et l'éventail de sécurité qu'elle propose.

2 - Une requête n'est pas lourde en soit. Maintenant, si tu as une table avec 1 000 000 d'enregistrements, que tu la croises avec une table qui en a tout autant, alors là oui, ca deviens lourd et encore que tout dépend de la création de tes clés et index. Mais avec un fichier texte, impossible de le gérer.

C'est exactement ce que je disais : la BD s'impose lorsque tu as des recherche a faire (et encore, faut que le model de donnee soit bien etudie). Par contre, faire un SELECT pour recuperer par exemple la liste des images d'un album est sans commune mesure plus consomateur qu'un readdir().

3 - La mise à jour des fichiers est totalement différentes d'une mise à jour en BDD : Pour un fichier, un problème de droit en écriture se pose si 2 personnes agissent en même temps. Autrement dis, l'un des deux sera jetté. Avec une BDD, si les 2 requêtes arrivent en même temps, l'une passera avant l'autre sans blocage aucun.

Ai-je dit le contraire ? Evidement s'il y a plusieurs utilisateurs interactifs qui sont amenes a modifier des informations, il est bien evident qu'une BD offre une facilite de developpement sans commune mesure par rapport a des fichiers. Mais ce n'est pas une raison pour que toutes les informations qui sont amener a modifier se retrouvent dans la dite BD.

Très franchement, si tu as un site "basique" réaliser à l'occasion de l'anniversaire de ton oncle et que tu veux compter le nombre de visiteur, alors oui prend un fichier. Pour le reste, c'est BDD.

Ben non, la je ne suis pas d'accord avec toi : tous les trucs massivement statique comme les sites promotionnels, les collections en tous genre (generation de rapports, album photos, articles statiques, voir meme les annuaires ...) ben tu te passes tres bien d'une BD.

Exemple tres concret : j'avais la charge d'un site web de ma boite ou est publie tous les rapports financiers (plusieurs centaines), utilises par plusieurs centaines de personnes. Ben la BD ne servait qu'a gerer les droits d'acces a ces rapports (paske a l'epoque, le directory LDAP n'etait pas encore finalise, depuis, c'est gere par les groups LDAP).

Pour le reste, j'avais des batchs qui tournaient la nuit et envoyait les PDF des rapports, ou des fichiers a plat d'ou etaient generer dynamiquement les graphiques qui correspondaient.

Le gros avantage de ce genre de truc, c'est qu'a 8 heures du mat, quant tous les managers arrivent et se connectent pour voir les chiffres du jours, ben ils n'accedent plus qu'a des donnees statiques, donc la BD n'a pas a absorbe des centaines de requettes qui ne font que fournir les meme resultats. En plus, les utilisateurs sont content car ils obtiennent ce qu'ils cherche imediatement, pas de temps de calcul.

Modifié 23 Août 2006 par destroyedlolo

[captain_torche]

Ca me fait plus penser à un système de cache, ça

[Portekoi]

_AT_destroyedlolo : Ton boss vient te voir 2 mois plus tard en te disant : "On va constituer un datawarhouse à partir de vos données sur les 12 derniers mois avec un moteur de recherche."

(Cas qui m'est arrivé)

Là, tu démissionnes

[destroyedlolo]

Ben non, car les donnees sont bien la, dans le DWH justement.

Je ne parlais que de la facon donc les utilisateurs accedaient aux donnees : Le DWH genere les rapports sous forme de PDF ou de fichiers plats et ils sont publies ou mise en forme par le web serveur.

Pas fou quant meme

[Portekoi]

j'avais la charge d'un site web de ma boite ou est publie tous les rapports financiers (plusieurs centaines), utilises par plusieurs centaines de personnes. Ben la BD ne servait qu'a gerer les droits d'acces a ces rapports (paske a l'epoque, le directory LDAP n'etait pas encore finalise, depuis, c'est gere par les groups LDAP).

Quand je lis cette phrase, je comprends que tu as une bdd qui ne te sert qu'à gérer les accès...

J'ai du mal comprendre alors.

Et comme le dis captain, c'est un système de cache que tu décris mais en aucun tu ne traites de la BDD

[destroyedlolo]

Ben autre cas alors (ha mais ).

La galerie de site web (bon, je sais, c'est un truc d'amateur, et y'a pas 15 milliards de gens qui vont dessus, mais bon, j'ai eu aussi a faire des sites de ce genre professionnellement).

Alors, il s'agit d'une collection de description de lieu touristiques avec des photos et tout et tout.

Pour le moment, tout est gerer sous forme de sous repertoires. C'est a dire, que pour les pages bien faite, si tu vas a La Clusaz par exemple, ben, tu te retrouve dans les repertoire France puis RhoneAlpes puis Clusaz, ce qui donne http://destroyedlolo.homeunix.org/galerie/...neAlpes/Clusaz/

A l'interieur, il y a des blocs de textes (qui sont sauvegardes dans des fichiers a plat) et des repertoires contenant les images. Ensuite, lorsque tu cliques sur le liens, une Action lance un PHP qui met en forme tout ca.

Alors ... ou serait l'interret d'avoir une BD dans ce cas la ?

Autre exemple : j'ai mis en place un monitoring d'une applie au taf. Pour tester si elle marche, je fais une sorte de PING sur l'applie et s'il echoue, je cree une ligne contenant l'heure dans un fichier a plat.

Lorsque l'on veut afficher les donnees, le site web recupere ce fichier et affiche des pastilles verte ou rouge en fonction des heures ou l'applie ne fonctionnait pas.

C'est leger, ca fonctionne bien, et je n'ai pas a me soucier de savoir si la BD est dispo ou pas (ca fait un point faible de moins, ce qui est important pour un monitoring).

Enfin dernier exemple : sur une des pages de mon intranet, j'ai une zone ou sont publies des messages informatifs generer automatiquement par des applies ou par les utilisateurs lorsqu'ils veullent partager quelques choses.

Ici aussi point de BD : les messages sont stoques dans un repertoire sous la forme de fichier texte de nom AAAAMMJJHHMMSS.num_unique.

Pour les afficher, readdir() suivit d'un sort et voila.

A nouveau, pas de bd, c'est trivial, simple et rebuste ... Pourquoi une BD dans ce cas la.

C'est d'ailleurs le meme truc que j'ai utilise pour afficher la liste des mise a jour de mon site sur la page d'acceuile ou calendrier de nos sorties ski ou rando (blog like )

Bon, sur ce, je vais rejoindre mes penates ... A+

[Portekoi]

Ben autre cas alors (ha mais ).

La galerie de site web (bon, je sais, c'est un truc d'amateur, et y'a pas 15 milliards de gens qui vont dessus, mais bon, j'ai eu aussi a faire des sites de ce genre professionnellement).

Alors, il s'agit d'une collection de description de lieu touristiques avec des photos et tout et tout.

Pour le moment, tout est gerer sous forme de sous repertoires. C'est a dire, que pour les pages bien faite, si tu vas a La Clusaz par exemple, ben, tu te retrouve dans les repertoire France puis RhoneAlpes puis Clusaz, ce qui donne http://destroyedlolo.homeunix.org/galerie/...neAlpes/Clusaz/

A l'interieur, il y a des blocs de textes (qui sont sauvegardes dans des fichiers a plat) et des repertoires contenant les images. Ensuite, lorsque tu cliques sur le liens, une Action lance un PHP qui met en forme tout ca.

Alors ... ou serait l'interret d'avoir une BD dans ce cas la ?

Ok, dans 2 ans, ton site fait un malheur. Résultat : Plus de 5000 visiteurs par jour sur ton site.... Tu me demandes toujours l'intérêt d'une BDD? Si oui, postule chez IBM

De plus, en terme de "practicité", c'est pas super : Comment gère X galeries portant toutes sur La Clusaz avec une description similaire? Tu dupliques les fichiers? Une même image va se retrouver dans X dossier..... pour rien?

Hum... pardon, mais comme solution, je n'aurais jamais opté pour celle ci car dans une optique d'évolution, c'est bancale....

Autre exemple : j'ai mis en place un monitoring d'une applie au taf. Pour tester si elle marche, je fais une sorte de PING sur l'applie et s'il echoue, je cree une ligne contenant l'heure dans un fichier a plat.

Lorsque l'on veut afficher les donnees, le site web recupere ce fichier et affiche des pastilles verte ou rouge en fonction des heures ou l'applie ne fonctionnait pas.

C'est leger, ca fonctionne bien, et je n'ai pas a me soucier de savoir si la BD est dispo ou pas (ca fait un point faible de moins, ce qui est important pour un monitoring).

Oui enfin là, on tombe sur le site pour le pappy qui a fêté ses 80 ans le week end dernier... Naturellement que l'on ne va pas crééer un BDD juste pour 1 ligne... mais maintenant, si tu as à monitorer X serveurs, tu feras plusieurs fichier 'log'? pourquoi ne pas mettre ca dans une BDD pour archiver, recroiser et ré-exploiter le résultat sur le long terme car une fois que ton fichier aura atteind 10 Mo, que feras tu?

Enfin dernier exemple : sur une des pages de mon intranet, j'ai une zone ou sont publies des messages informatifs generer automatiquement par des applies ou par les utilisateurs lorsqu'ils veullent partager quelques choses.

Ici aussi point de BD : les messages sont stoques dans un repertoire sous la forme de fichier texte de nom AAAAMMJJHHMMSS.num_unique.

Pour les afficher, readdir() suivit d'un sort et voila.

Oui mais toujours pareil... si tu veux exploiter ses fichiers sur le long terme, tu auras dans ton dossier 15000 fichiers textes sans aucune relation entre eux car c'est bien ca le problème : Comment gérer les relations entre fichiers? Ca complique singulièrement les choses non?

A nouveau, pas de bd, c'est trivial, simple et rebuste ... Pourquoi une BD dans ce cas la.

C'est d'ailleurs le meme truc que j'ai utilise pour afficher la liste des mise a jour de mon site sur la page d'acceuile ou calendrier de nos sorties ski ou rando (blog like )

Bon, sur ce, je vais rejoindre mes penates ... A+

Tout ca pour dire qu'utiliser une BDD ne coute rien mais utiliser des fichiers peut engendrer bien des soucis :

1 - Problème de stockage

2 - Problème d'exploitation (un fichier de 15 Mo, dur à gérer)

3 - Problème d'accès (X utilisateurs en même temps)

4 - Aucun relationnel possible

Donc oui, tu as raison : Lorsque c'est pour un petit enregistrement, une appli qui n'a aucune connexion avec une autre (ce qui déjà serait bizarre), alors oui, utiliser un fichier texte peut être intéressant mais dans les 3 exemples que tu as cités ci-dessus, j'aurais utiliser une BDD.

Bonne soirée

Portekoi

[Anonymus]

Je ne me pose même pas la question de la base de données par rapport aux fichiers texte. Mysql est autrement plus rapide que php, point barre. Et les cas où mysql est moins rapide, c'est qu'il faut changer de serveur. Mon site perso gère 3 millions d'enregistrements, et je n'imagine pas le quart d'une seconde que le serveur puisse faire ca en fichier texte..

La base de données est un système de fichiers texte hyper optimisé. Pourquoi réinventer le fil à couper le beurre ?

[destroyedlolo]

>> Ok, dans 2 ans, ton site fait un malheur. Résultat : Plus de 5000 visiteurs par jour sur ton site.... Tu me demandes toujours l'intérêt d'une BDD? Si oui, postule chez IBM

Non, la je ne suis pas d'accord. Dans des cas comme ca, j'evite d'avoir 5000 requetes dans la base ... Et c'est justement l'interet : la seule chose que j'ai ce sont des requettes HTTP vers les images, et 1 scripts PHP par visiteur qui genere a la vole la page. Que tu utilises ou non une BD, de toute facon, tu ne coupera pas a ces 2 etapes.

(evidement, on ne parle que de visiteurs et non de redacteurs).

>> De plus, en terme de "practicité", c'est pas super : Comment gère X galeries portant toutes sur La Clusaz avec une description similaire? Tu dupliques les fichiers? Une même image va se retrouver dans X dossier..... pour rien?

Et pourquoi Si je souhaites acceder a une images sur la Clusaz, je sais ou la trouver car son URL est normalisee. Il n'y a strictement aucune raison qu'elle se trouve dans un autre repertoire.

>> Oui enfin là, on tombe sur le site pour le pappy qui a fêté ses 80 ans le week end dernier... Naturellement que l'on ne va pas crééer un BDD juste pour 1 ligne... mais maintenant, si tu as à monitorer X serveurs, tu feras plusieurs fichier 'log'? pourquoi ne pas mettre ca dans une BDD pour archiver, recroiser et ré-exploiter le résultat sur le long terme car une fois que ton fichier aura atteind 10 Mo, que feras tu?

Il est evident que je n'etais pas rentre dans les details : je monitore actuellement une disaine de serveurs, et le nom des fichiers cree est : Serveur.AAAAMMJJ.heath ce qui fait que j'ai une segregation sur le nom du serveur et sur la date.

>> Oui mais toujours pareil... si tu veux exploiter ses fichiers sur le long terme, tu auras dans ton dossier 15000 fichiers textes sans aucune relation entre eux car c'est bien ca le problème : Comment gérer les relations entre fichiers? Ca complique singulièrement les choses non?

La seule chose dont j'ai besoin, c'est d'avoir une segregation par non de serveur et un trie par date. J'ai les 2 infos dans le nom meme du fichier.

>> Tout ca pour dire qu'utiliser une BDD ne coute rien mais utiliser des fichiers peut engendrer bien des soucis :

1 - Problème de stockage

Je ne vois pas ou : une donnee prend beaucoup plus de place dans une BD que dans un simple fichier.

>> 2 - Problème d'exploitation (un fichier de 15 Mo, dur à gérer)

Non : multitude de fichiers. Si le nombre de fichiers devient trop gros (c'est mon cas sur certaines donnee que je dois archivee "longtemps"), je cree simplement des sous repertoire specifique a chaque machine. A nouveau, il n'y a aucun croisement a faire entre machine.

Y'a que sur les purges ou un

DELETE FROM table WHERE ...

est plus efficace qu'un

find . -ctime -10 -exec rm {} \;

.

Mais bon, ca ne passe qu'une fois par jour.

>> 3 - Problème d'accès (X utilisateurs en même temps)

Non, pas lorsque c'est uniquement en lecture.

>> 4 - Aucun relationnel possible

Tout a fait d'accord : et c'est d'ailleurs ce qui me fait penche en faveur d'une DB ou d'un fichier a plat.

>> Je ne me pose même pas la question de la base de données par rapport aux fichiers texte. Mysql est autrement plus rapide que php, point barre.

Ben, les tests que j'ai effectue me prouve le contraire. Pour mesurer l'occupation disque des databases de ma boites, j'ai choisi de mettre les donnees en BD (car il y a des jointures a faire pour certains rapport). La volumetrie est a peut pret identique au monitoring que j'ai decrit plus haut ... sauf que j'ai abandonne l'idee de generer les graphismes a la vollee car ... ca prend trop de temps et ca bouffe les ressources de la machines. Bref, vu que ces donnees sont modifiees 1 fois par jour, je fais tourner des batch chaque nuit.

Avant que ca ne vienne sur le tapi, les requettes SQL et les schema de la base de donnee ont ete optimises en profondeur (et vu la vitesse de mon serveur de dev, ce n'etait pas un luxe )

>> Et les cas où mysql est moins rapide, c'est qu'il faut changer de serveur.

C'est vraiment une vision a la microsoft Ton serveur est trop lent, ne cherche surtout pas a savoir d'ou ca vient et change le

Perso, je prefere rentabiliser ce que j'ai et laisse de la pluissance aux autres utilisateurs de mes machines.

>> Mon site perso gère 3 millions d'enregistrements, et je n'imagine pas le quart d'une seconde que le serveur puisse faire ca en fichier texte..

Mon site perso contient plus de 5000 photos et elles ne sont pas gere par une BD ... simplement parce qu'il n'y avait pas de besoin. Le seul endroit ou la BD est utilisee, c'est pour gerer les stats et pour certains applie ou il y a reelement des croisement a faire.

>> La base de données est un système de fichiers texte hyper optimisé. Pourquoi réinventer le fil à couper le beurre ?

La BD est optimise pour faire des REQUETTE. L'utilisation systematique d'un BD lorsqu'il n'y a aucun relationnel entre les donnees est simplement du gaspillage de ressources.

Bha, on n'arrivera pas a se mettre d'accord : mais ce n'est pas grave : ca prouve simplement qu'il y a toujours plusieurs facon de faire les choses. BD ou pas BD, pour moi ca depend surtout de l'utilisation des donnees.

[Portekoi]

Très franchement, je vais pas te reprendre en QUOTE un par un. Tes arguments pour ma part ne sont pas recevables dans la mesure ou une gestion par fichier ne peut pas évoluer aussi facilement qu'une BDD concu pour et tu ne peux gérer un enregistrement choisi sur des milliers avec tes fichiers alors qu'avec une BDD, oui. Avec un fichier, tu ne peux pas requêté pour prendre UN enregistrement ou alors, tu dois parcourir tout ton fichier.

Si demain on te demande de faire évoluer de facon significative ton application, tu seras coincé et étant développeur moi même, je pense moi aussi savoir de quoi je parle.

Donc oui, utiliser les fichiers textes de temps à autre ok. Mais dans tout ce que tu as décris, en aucun cas j'aurai procédé ainsi.

EDIT : Une question me vient à l'esprit : Comment procèdes tu pour modifier/supprimer UN enregistrement? Et dans le cas où tu me répondras "Pas besoin", comment feras tu lorsque tu en auras besoin?

[Remi]

Personnellement, j'utilise très peu les BDD.

Les avantages à mes yeux à ne pas utiliser MySql sont :

- L'exécution est bien plus rapide

- les moyens mis en oeuvre peuvent être optimisés

- on a la maîtrise de 100% du code

- maintenance, sauvegardes et sécurité sont plus faciles à assurer

- l'hébergement est bien plus simple (le talon d'Achille des mutualisés est MySql)

Les inconvénients sont surtout qu'il ne faut pas avoir peur de programmer et que la maintenance est plus difficilement transmissible (s'il y a des gros volumes de données, parce que sinon ce n'est pas un problème et quiconque a eu à reprendre des applis MySql écrites par d'autres savent que tout n'est pas toujours rose).

Ceci dit, je ne cherche à convaincre personne : certains vont ouvrir une DBB pour incrémenter un compteur de visites...

MySql a le gros avantage d'être accessible à un grand nombre de webmasters/programmeurs en offrant un pseudo-language très performant et facile à mettre en oeuvre. C'est normal qu'il se soit imposé et il est certainement là pour longtemps encore. Mais, en informatique, il n'y a rarement qu'une seule façon de faire les choses...