Bonjour,

Jusque là je n'ai toujours utilisé que Mysql comme base de données avec PHP, mais je vais commencer à développer un site dont la base de données pourrait très vite être assez grosse, et le traffic dessus pourrait nécessiter plusieurs serveurs à l'avenir (je n'en suis pas encore là mais enfin bon faut prévoir, car s'il faut tout changer après...).

Ma question est donc qu'est ce qu'il vaut mieux que j'utilise comme base de données ? Mysql ? PostgreSQL ? autre ?


Merci à vous.

Salut,

Ce n'est pas un pb de traffic Mysql ou postgresSql montent bien en puissance mais je parlerais du pb de license! postgresSql est passé à la license OpenBsd (ou un truc qui ressemble) donc beacoups plus libre que la license de Mysql en plus le moteur InnoDb de Mysql a été racheté par Oracle!! donc pour l'avenir OpenSource de Mysql des questions sont posées!!

Salut,

Si tu prévois une base de donnée de plusieurs go avec un bon nombre d'opérations simultanées, tourne toi vers PostgreSQL.

Sinon, fournis-nous plus d'informations sur l'usage que tu comptes en faire (bdd d'articles, forum, ecommerce, sondage,...), cela pourrait aider les personnes d'expérience à te conseiller

Très honnêtement, si ton projet devient important, un forum n'est pas le meilleur endroit pour choisir un SGBD.
Il va falloir que tu fasses une liste de ce qui est important pour toi, et comparer les différents outils du marchés.
Je connais assez bien les SGBD mais je me risquerai certainement pas à te conseiller tel ou tel produit.

Merci à vous, j'ai pu me renseigner un peu entre temps en faisant des recherches sur les comparatifs de fonctionnalités donc c'est bon.
Car le truc c'est que je ne connais pas bien PostgreSQL mais mysql ça va, d'où ma question.. mais j'ai quelques pistes de réponses maintenant.

Par contre est-ce quelqu'un s'est déjà risqué dans des migrations mysql -> postgresql ou l'inverse, savoir si au pire des cas c'est toujours faisable sans trop de galères ?


ps pour Reivilo : c'est pour des stats de sites avec traffic assez sympathique.


Merci pour vos réponses en tout cas

Si tu veux réussir une migration d'un SGDB vers un autre, il faut l'anticiper.

1. Commence par modéliser tes bases de données. Passe par un outil comme PowerAMC 12, tu as une période d'éssai de 15 jours.
MCD->MPD-> Génération de script de DB.
N'hésite pas à générer des scripts pour +sieurs SGBD : mySQL, postgreSQL, SqlServer, Oracle, DB2, etc....
Garde les au chaud, on sait jamais. Si ton service explose et que tu as besoin d'un oracle


1. Bis Dans la mesure du possible, n'utilise aucune syntaxe SQL spécifique à un SGBD donné. Plus tu seras proche des standard SQL, plus la migration sera facile.

2. Découpe ton application en couche logique : dao/métier/présentation.
Dans ta couche dao tu vas implémenter les fonctions ( ou objet ) d'accés aux données.
tu auras une arbo du style :
dao/mysql/*.php
dao/pgsql/*.php
dao/oracle/*.php
etc...

Ta couche métier fera appel aux fonctions/objet de ta couche dao sans jamais savoir quel est le mode de stockage derrière.
Si tu réussis bien cette séparation, changer de SGBD reviendrat à réecrire une couche dao.

Dans ton cas, tu n'as peut-être pas intérêt à passer par des outils d'abstraction d'accés aux SGBD ( style PEAR :: DB ). Ces outils sont géniaux pour te simplifier l'accés aux DB, par contre tu vas perdre en terme de performance.

Dans un fichier Include tu définis ton path vers la bonne couche DAO.
En théorie, la migration d'un SGBD consistera juste à modifier ce path. En théorie .

2. Bis Il faudrat prévoir des scripts de migration de données. ça devrait pas être le plus dur.

3. Ta couche métier. Pour simplifier la migration d'un SGBD vers un autre tu as tout intérêt a implémenter ta logique métier en dehors du SGBD.
En clair : transférer les éventuelles procédures stockées du SGBD vers ta couche métier.
Je suis pas tjrs d'accord avec ce point. Les procédures stockées ont l'avantages d'être plus performantes.
ça c'est à voir en fct de ton projet et de tes habitudes de devs.

4 Optimisation des performances :

Pour la mise en place d'un outil statistique tu as tout intérêt à séparer le stockage de tes données dans deux bases séparées :

- Premiere base ( DBLog ) : la base de recueil des informations
- Deuxième base ( DBStat ) : la base de consolidation des données.

Cette séparation te permettra, le jour où tu en auras besoin, de mettre tes deux bases sur deux serveurs différents, sans trop de pb.

Ces deux bases ont des spécificités totalement opposées :
- DBLog : sera quasi exclusivement en écriture
- DB Stats : sera quasi exclusivement en lecture

- DBLog : Tu ne met aucun index sur cette base. Les index améliorent les performances des SELECT. Ils ralentissent les opérations d'INSERT et d'UPDATE.
- DBStat : Tu use et abuse des index dans cette base pour optimiser les opérations de lectures.

DBLog sert à recueillir les stats en temps réels. Chaque nuit tu passes tes scripts de consolidation qui vont transférer les données de DBLog vers DBStats.
Chaque matin tes clients auront leurs stats dispo.

5. Quelle solution de stockage

Petite réflexion perso :

Est-ce qu'un SGBD est la meilleure solution de stockage pour un outil statistique ?
Les SGBD sont performant sur des modèles de données relationnes ?
Les statistiques sont-elles des données relationnelles ?

La phase de consolidation dans un SGBD => Ok, cela pourrait simplifier l'implémentation du projet.

La phase de Log => Est-ce qu'un SGBD est vraiment la structure la plus performante pour logger des stats ?
Est-ce qu'un système de fichier ne serait pas plus performant ?
Comment font xiti, eStat et les autres pour recueillir leurs données ?