Pripojeni ke 2 databazim

Provozuji aplikaci kde kazdy klient ma vlastni databazi. Nektera spolecna data jsem doposud mel v souborech. Uvazuji o tom, ze je umistim konecne do databaze, ale nechci je davat do vsech klientskych DB. Proto budu mit vyhrazenou DB, a tim padem mam 2 moznosti:

Pripojit se ke 2 databazim najednou v kazdem scriptu

Udelat externi mini-aplikaci, ktera bude cist udaje ze spolecne DB a predavat ji hlavni aplikaci pres XML, JSON atd.

Jestli mate zkusenosti s necim podobnym, budu rad, kdyz se podelite. Zajima me nakolik vyroste riziko a zatizeni serveru u varianty 1. Jestli to je neco co mam brat vazne v uvahu anebo jestli jde o bezne pouziti. 2. varianta bude asi lepsi z pohledu skalovatelnosti, ale je pracnejsi a nejspis pomalejsi. Nebo... mozna znate lepsi reseni.

Mám zkušenost s více connectionami do relativně oddělených agend - bez problému. Pokud jsou ta data integrální součástí aplikace, asi bych se (podle technologie) snažil je dát do jedné DB - ani ne tak kvůli výkonu, ale spíš kvůli pohodlí/blbovzdornosti - referenční integrita, ORM, .. Taky popřemýšlej, jestli se nemůže stát, že by někteří klienti nemohli mít ta obvykle společná data společná, ale nějaký extrabuřt. Jiné názvosloví zdánlivě univerzálních věcí, v období zafixované kurzy měn a podobně. To by ses pak v connectionstringách zapastil a lepší by bylo udělat (podle mě docela jednoduché) individualizovatelné pumpy ze zdroje do jednotlivých klientských DB.

Můžeš trochu přiblížit strukturu tvých databází?Jsou nějaké rozdíly (ne v obsahu ale ve struktuře) v databázích jednotlivých klientů? Mají klienti rozdílnou funkcionalitu (tj. pro různé klienty se spouští různý kód)?Třeba se mýlím, ale je možné, že by toto všechno šlo zjednodušit a dát do jedné databáze. Buď by 1) každý klient měl svou tabulku, nebo 2) by bylo rozlišení na úrovni řádku přes id klienta (klienti uloženi v tabulce).---Nenapsal jsi, o který databázový systém se jedná a jestli jsou všechny databáze v rámci jednoho tohoto systému (SŘBD). Ve většině běžných relačních databází se lze na tabulky odkazovat i absolutně (SELECT * FROM jmeno_databaze.jmeno_tabulky). Pak bys mohl mít jen jedno připojení. Řešilo by to tvůj problém?

Ty databáze jsou na různých serverech? Pokud ano a ta společná bude na jednom, tak obě varianty spoléhají na to, že se mu nic nestane.

Dekuji za reakce,2 ndpudo. To s tim pumpovanim do vsech DB zni zajimave, ale v pripade kdyz jich budou stovky, upgrade muze trvat prilis dlouho... i kdyz jde jen o par malych tabulek. To je co vlastne resim - jestli to pumpovat do vsech DB anebo davat pouze do 1 a pristupovat pak ke 2 db pri kazdem pouziti aplikace. Zatim jsem se nerozhodl. Extraburty nechavam v jednotlivych klientskych DB. :) Jinak, hlavne jde o texty a dalsi spolecna data, ktera jsou casti aplikace.2 crs, slo by teoreticky dat vse do 1 databaze a jak pises rozlisit pomoci ID klienta, ale nechci to delat z nekolika duvodu. Ten hlavni ted je bezpecnost a citlivost dat. Predstava, ze by se kvuli nejake chybe aplikace klient dostal k datum jinych klientu je hroziva. Ale jsou i jine duvody.Je to MySQL (asi 30 tabulek/db), zatim 1 system na 1 serveru. Abych mohl 1 pripojenim pristupovat ke 2 DB, asi musim povolit pristup k te spolecne DB vsem DB uzivatelum. To je zajimavy napad, o kterem jsem zatim nepremyslel. Prozatim kazda DB mela sveho uzivatele a vlastni heslo.2 Souki. Zatim je vse na 1 serveru, ale mas pravdu. Jak bys to resil? Duplikoval do vsech DB tabulky se stejnym obsahem? Ted zase vaham pro tuto variantu s tim, ze tam udelam nejakou synchronizaci s master DB, kde by byly pouze ty spolecne tabulky.

Pokud je to na jednom serveru, tak bych vůbec nic neřešil. Společná data dej do jedné databáze a uživatelům do ní nastav read-only přístup. U e-shopů máme přesně takhle ukládany informace typu "seznam pošt" a podobně.Při více serverech pak je nejpřímočařejším řešením replikace společné databáze. Šikovnější by ale mohlo být udělat to asynchronně a můžou se zachovat ty současné soubory. Na centrálním serveru bych ukládal hodnotu určující verzi databáze. To může být nějaký hash nebo timestamp posledního uložení. Když se pak v "satelitu" bude pracovat se společnými daty, tak se nejdřív koukne na centrální hash, zda odpovídá tomu lokálně uloženému. Pokud ne, tak si z centrálu stáhne aktuální data a aktualizuje hash.Hash může být v satelitu třeba v APC nebo i v souboru. Data můžou být soubory nebo třeba jeden soubor osahující sqlite databázi (záleží, co je to za data). Pokud nebude centrální web dostupný, použijí se cachovaná data a nic se neděje.Přenášet se bude pouze hash, takže všechna data se budou číst lokálně. Hash se navíc nemusí přenášet vždy a může se kontrolovat třeba jen pokud je starší jak hodina (opět záleží na typu dat).Při aktualizaci dat akorát pozor na paralelní přístup. Během aktualizace by se měl udělat nějaký zámek, ať se to neaktualizuje 100x paralelně. Pokud další request narazí na zámek, použije data z cache.