Bonjour,
Je suis en train de programmer une application web  avec PHP/MySQL, et pour ma base de données doit contenir plusieurs table(gestion de commande,livraison, personnel,...),
Mais je vous demande, qui sont les avantages de chaque situation suivante :
*Une seule base de données pour toute l'aplication.
*Plusieurs base de données.
Merci pour votre aide

plusieurs bases pour la même appli?

Oui, car je veux separer les differents gestions (la gestion de livraison de la gestion de personnel par exemple , pour bien maitriser les données). et l application est hebergée en local, donc je peux,ds MySQL, créer 3 ou 4 base de donées et faire  le lien entre eux.
et c ça la question qui est mieux? une seule ou plusieurs base de donées?

M'enfin quel intérêt de faire plusieurs bases sur le même serveur pour une seule appli?
D'autant qu'il y aura probablement des données qui se croisent, hein...

Plusieurs bases pour la même appli: interêt tendant vers 0.
Par contre si tu veux jouer à fond la carte de l'encapsulation, de la séparation des données etc. tu peux jouer avec les schemas voire même avec les tablespaces (Postegres>=8.0, Oracle), avec des droits différents etc.

ça dépend des besoins, en général plusieurs bases = plus cher puisque plus de ressource et plus d'admin... mais ça garantit l'isolation des données et l'indépendance de l'infrastructure... pour des clients différents ça évite de les planter tous si une base est crashé
 
Edit : pour une seule appli ça parait un peu superflu en effet

Je répète ce que je disais plus haut: différents tablespaces suffisent

en effet... j'avais pas le contexte au moment de répondre

Jusqu à mnt, j attend une reponse exacte,
pour les tablesspaces ça sert a koi SVP ?

Tu ne veux pas qu'on te la code non plus ? Tu te crois où ? Les gens ici t'ont donné des réponses basées sur leurs connaissances et leur expérience, après tu te débrouilles, mon grand.
Et google, c'est pas pour les cochons.

c pas ça, car j ai fs 2 conceptions une avec une seule base et l autre avec 4 bas de donées, et me je suis bloquée là, la quelle je dois choisir et il faut argumenter la solution choisie, vous me comprener, ne sois pas si nerveux !!. on est là pour l aide seulement !!. moi aussi si klk 1 est curieux je vais avec lui jusq au bout pour lui convaincre ...

4 bases de données pour une seule appli c'est strictement ridicule...

bah je les ai fait pour separé les differentes gestion (livraison, stock,personnel, commande)

tu veux une réponse exacte ? en voici une : 4 bases c'est un grand n'importe quoi, une absurdité sans nom. moktar a raison, les tablespaces servent justement à gérer ce cas de figure (tablespace = structure indépendante contenant ses propres tables, indexes et autres objets, exactement ce que tu veux), à toi donc d'apprendre à les utiliser.

Merci bcp,
mnt t as repondu juste, lol

Sinon accessoirement pour savoir précisement à quoi ça correspond il faut éplucher la doc.
Par exemple: http://www.postgresql.org/docs/8.1 [...] paces.html
 
Sinon question con, techniquement parlant, tu fais comment pour gérer en même temps 4 bases de données? Pour les contraintes d'intégrité référentielles par exemple? Je serais curieux de savoir...

Si les données sont vraiment (quasi) indépendantes, pourquoi pas. Mais si les tables sont liées entre elles, il est plus cohérent qu'elles soient dans la même base  

Ma solution est exactement votre reponse, mais l'encaderant exige l'autre solution de séparation. je vous ai demandé d'argumenter(donner les avantages) pour que je puisse argumenter ma solution.
Merci pour votre aide

- intégrité référentielle inapplicable
- augmentation de l'espace disque requis
- difficulté de déploiement
- aucune interaction possible entre les bases (rejoint le probleme de l'intégrité référentielle)
- maintenance difficile (sauvegardes, etc...)
- etc ... etc...

Pour la maintenance et les sauvegardes Harko on peut en débattre Autant c'est plus compliqué, autant l'encapsulation apporte des avantages certains en matière de sécurité. On peut par exemple décider d'appliquer des politiques de sauvegarde deifférente suivant la partie de la base de donnée (tous les jours pour les données super sensibles, 1 fois par mois ou même 1 fois à l'install pour les données "de base" etc.).
L'argument principal que je vois c'est concernant les problèmes d'intégrité: pour avoir bossé dessus, je peux dire qu'il est strictement impossible de pouvoir garantir la fiabilité des données avec une telle approche. L'exemple con, on met à jour des données dans une base, et le système plante (bug, panne etc.) avant la mise à jour dans les autres bases: on fait quoi?
Après pour ce qui est de la difficulté du déploiement de la maintenance... ça prète à débat, car d'aucuns préfèrent investir dans des systèmes chiants à maintenir mais garantissant une sécurité optimale.