Oui, c'est possible et mon entreprise le fait. Je ne vais certainement pas dire que c'est intelligent, cependant. Nous avons un système d'automatisation du marketing SAAS. Les bases de données de certains clients ont plus d'un million d'enregistrements. Nous traitons une deuxième base de données "commune" qui a une table "fulfillment" qui suit les e-mails, les lettres, les appels téléphoniques, etc. avec plus de 4 millions d'enregistrements, ainsi que de nombreuses autres tables partagées très volumineuses. Avec une indexation appropriée, l'optimisation, la maintenance d'un serveur de base de données séparé et éventuellement le clustering (ce que nous n'avons pas encore à faire), vous pouvez gérer BEAUCOUP de données ...... dans de nombreux cas, ceux qui pensent que cela peut ne gèrent que quelques centaines de milliers d'enregistrements et travaillent sur un produit concurrent pour gagner leur vie. Si vous doutez encore de sa validité, considérez que selon les métriques de clustering de MySQL, un cluster de 8 serveurs peut gérer 2,5 millions de mises à jour PAR SECONDE. Pas trop minable du tout.....
Le problème avec l'utilisation de deux bases de données est de jongler avec plusieurs connexions. Est-ce difficile ? Non, pas vraiment. Vous créez différents objets et référencez vos classes de connexion en fonction de la base de données souhaitée. Dans notre cas, nous atteignons la classe d'entreprise de la base de données principale pour déduire le nom de la base de données client, puis construisons la deuxième connexion en fonction de cela. Mais, lorsque vous jonglez entre ces connexions, vous pouvez rencontrer des erreurs qui nécessitent un débogage supplémentaire. Ce n'est pas seulement "Est-ce que ma requête est valide?" mais "Est-ce que j'obtiens réellement la bonne connexion à la base de données?" Dans notre cas, une session abandonnée peut provoquer toutes sortes d'erreurs PDO car le système ne peut plus savoir à quelle base de données client accéder. De plus, du point de vue de la maintenabilité, c'est un processus effrayant d'essayer de pousser les mises à jour de la structure de la table vers 100 bases de données en direct différentes. Oui, il peut être automatisé. Mais une erreur et vous avez renversé BEAUCOUP de gens et fait une tonne de travail supplémentaire pour vous-même. Maintenant, calculez le développement et les tests supplémentaires nécessaires pour jongler avec les connexions et pousser les mises à jour... cela vous permettra de mesurer si cela en vaut la peine.
Ma recommandation? Trouvez un hébergeur qui vous permet de mettre deux machines sur le même réseau local. Nous avons choisi Linode, mais qui vous utilisez n'a pas d'importance. Commencez avec votre serveur de base de données dédié, planifiez à l'avance la mise en cluster lorsque cela est nécessaire. Conservez tout votre contenu dans une seule base de données, indexez et optimisez religieusement. Enfin, trouvez un TRÈS bon type DB et traitez-le bien. Avec autant de données, un excellent DBA serait indispensable.
