ugrás a tartalomhoz

Érdemes több adatbázis szervert támogatni?

janoszen · 2005. Nov. 28. (H), 21.47
Sziasztok!

Megint egy kérdéssel fordulnék hozzátok. Előfordult-e már veletek, hogy egy webes fejlesztés során több adatbázist használjatok párhuzamosan?

Azért kérdem, mert egy rendszert fejlesztek, aminek eléggé flexibilisnek kellene lennie ahhoz, hogy az igények 98%-ára fel legyen készülve. Mivel az adatbázis kezelése a maghoz tartozik, később nehéz rajta változtatni.

Szóval kérdés: fel kell-e készítenem a rendszert több (különböző típusú) adatbázis kezelésére?
 
1

termék, szolgáltatás, stb

Hojtsy Gábor · 2005. Nov. 28. (H), 22.08
Nos, a kérdés megválaszolásához többet kellene tudni a helyzetről. Ha eladásra szánod a terméket, akkor szinte biztosan érdemes több adatbázisra tervezni, ha egy profi alkalmazás, akkor könnyen lehet, hogy profi(bbnak gondolt) adatbázisokkal fogják használni. Ha szolgáltatásként lesz elérhető, vagy csak belső használatra, akkor függ a cégmérettől, a feladatokban résztvevő más adatbázisoktól, stb.

Általánosságban ha nem szoktál még meg egy adatbázis rendszert sem kifejezetten, akkor jól teszed, ha több adatbázisra tervezel, de tisztában kell lenned azzal, hogy bizonyos teljesítményt, integritást, stb javító dolgokat nem használhatsz (pl. tárolt eljárások, tranzakciók, stb), mert ezek támogatása nem minden adatbázisban elvárható, ahol pedig lehetséges a szimulálásuk, ott eléggé lassú általában a módszer.
2

Érdemes

aries · 2005. Nov. 29. (K), 09.50
Érdemes vele foglalkozni, már csak azért is, mert vannak kifejezetten erre kihegyezett API-k. A tárolt eljárások használata régen sem volt javasolt, mert az adatbázisszerver nehezebben skálázható, mint a kliensek. A tranzakció sajnos tényleg fogós kérdés, bár szinte mindegyik modern SQL-szerver támogatja már, de más "dialektusban".

Ha nem használsz nagyon extrákat, akkor mindenképpen érdemes átállni, már csak azért is, mert nem nagy munka.
--
Aries
http://aries.mindworks.hu
4

skálázhatóság

zsepi · 2005. Nov. 29. (K), 11.09
A tárolt eljárások használata régen sem volt javasolt, mert az adatbázisszerver nehezebben skálázható, mint a kliensek

Ezt kifejtenéd bővebben? Akár linkek formájában is... Én most éppen a php-s kliensből viszem át a logikát tárolt eljárásokba, mert hirtelen kiderült, hogy több kliens programra is szükség lesz, akik azonos feladatokat (is) végeznek. Így aztán érdekelne, hogy miért is nem skálázható a dolog....
3

Nem a tamogatas a kerdes

janoszen · 2005. Nov. 29. (K), 09.57
Udv!

Koszi szepen a velemenyeket, de igazabol nem erre voltam kivancsi. Az, hogy tobb fajta adatbazist tamogasson, az nem kerdes. A kerdes sokkal inkabb az, hogy ha egy szerverre folteszik a rendszert (CMS) akkor ott azon a szerveren fognak-e akarni EGYSZERRE monjuk MySQL-t es teszem azt Oracle-t hasznalni.

Szoval a kerdes az, hogy parhuzamos kapcsolatokat erdemes-e tamogatni.
5

Nem biztos, hogy értem...

zila · 2005. Nov. 29. (K), 13.16
Azt kérdezed, hogy a te rendszered a táblái egy részét egy mysql másik részét oracle tárolja? Ez szerintem nem kívánatos. Olyan elképzelhető, hogy másik üzleti rendszerhez kell kapcsolódni, adatot cserélni stb. ez a tőled független rendszer lehet másik adatbázis. Én magamtól nem csinálnék olyat, hogy a rendszerem egyszerre több különböző db motort használjon a normális működése közben...

üdv,
Zila
6

Koszi

janoszen · 2005. Nov. 29. (K), 14.33
Koszi, erre lettem volna kivancsi. Errol szeretnek velemenyeket begyujteni, hogy talalkozott-e mar valaki ilyen keressel. Ha valaki tud olyan esetrol, amikor nagy portalmotornal akar, de elofordulhat, akkor irjon. :)
7

Speciális funkciók

aries · 2005. Nov. 29. (K), 14.42
Csak speciális funkciók esetében, pl. mysql fulltext indexelés + (postgresql) view-k iránti igény... A kérdés hasonló ahhoz, hogy elképzelhető-e olyan, hogy egy alkalmazást több programnyelven írjanak meg. Elképzelhető, a leggyakoribb eset akkor szokott fellépni, amikor egy meglévő rendszert kell toldani-foldani.
--
Aries
http://aries.mindworks.hu
8

joinok, stb

Anonymous · 2005. Nov. 29. (K), 15.33
Igen, az a ciki benne, hogy joinolni nem tudsz több adatbázis motor táblái felett, ezért mindig szinkronizálni kell az adatokat, de ha ennyire megéri a szolgáltatások miatt, akkor egyedi döntés esetén talán értelmes...