Ja, det er muligt, og mit firma gør det. Jeg vil bestemt ikke sige, at det er smart. Vi har et SAAS marketing automation system. Nogle klienters databaser har mere end 1 million poster. Vi beskæftiger os med en anden "fælles" database, der har en "opfyldelse"-tabel, der sporer e-mails, breve, telefonopkald osv. med over 4 millioner poster, plus adskillige andre meget store delte tabeller. Med ordentlig indeksering, optimering, vedligeholdelse af en separat DB-only server og muligvis clustering (hvilket vi endnu ikke skal gøre) kan du håndtere MANGE data......i mange tilfælde kan de, der tror, det kan kun håndtere et par hundrede tusinde plader arbejde på et konkurrerende produkt for en levende. Hvis du stadig tvivler på, om det er gyldigt, så overvej, at pr. MySQL's klyngemålinger kan en 8-serverklynge håndtere 2,5 millioner opdateringer PER SEKUND. Slet ikke for lurvet.....
Problemet med at bruge to databaser er at jonglere med flere forbindelser. Er det hårdt? Nej ikke rigtigt. Du opretter forskellige objekter og refererer til dine forbindelsesklasser baseret på hvilken database du ønsker. I vores tilfælde ramte vi hoveddatabasens virksomhedsklasse for at udlede klientens db-navn og bygger derefter den anden forbindelse baseret på det. Men når du jonglerer med disse forbindelser frem og tilbage, kan du løbe ind i fejl, der kræver ekstra fejlretning. Det er ikke kun "Er min forespørgsel gyldig?" men "Får jeg faktisk den rigtige databaseforbindelse?" I vores tilfælde kan en afbrudt session få alle mulige PDO-fejl til at udløse, fordi systemet ikke længere kan holde styr på, hvilken klientdatabase der skal tilgås. Plus, fra et vedligeholdelsessynspunkt er det en skræmmende proces at forsøge at skubbe tabelstrukturopdateringer til 100 forskellige live-databaser. Ja, det kan automatiseres. Men en slip op, og du har væltet en masse mennesker og gjort et væld af ekstra arbejde for dig selv. Beregn nu den ekstra udvikling og test, der kræves for at jonglere med forbindelser og push-opdateringer....det vil være din målestok for, om det er umagen værd.
Min anbefaling? Find en vært, der giver dig mulighed for at sætte to maskiner på det samme lokale netværk. Vi valgte Linode, men hvem du bruger er irrelevant. Start ud med din dedikerede databaseserver, planlæg i forvejen for at lave klyngedannelse, når det er nødvendigt. Gem alt dit indhold i én DB, indekser og optimer religiøst. Find endelig en RIGTIG god DB-fyr og behandl ham godt. Med så mange data ville en god DBA være et must.