ugrás a tartalomhoz

Adatbázis kapcsolat hossza

tomiie · 2011. Jan. 10. (H), 04.41
Sziasztok!

Az adatbázissal való kapcsolattartás hosszáról olvastam már ezt is, azt is, de mégsem tudom eldönteni, hogy mi a helyes megoldás, ezért kérdeznélek Titeket.
Mikor érdemes megnyitni a kapcsolatot az adatbázissal és ezt meddig szabad fenntartani? Le kell zárni minden oldalon? Azonnal le kell zárni, ahogy csak lehet, vagy elég az oldal alján? Egyáltalán érdekes-e, hogy a kód melyik részén van megnyitva, illetve lezárva a kapcsolat az adatbázissal? Van általánosan jó megoldás, vagy az oldal méretétől és terhelésétől függ?
Amennyiben ettől függ, úgy legyen szó egy viszonylag nagy terhelésű oldalról, ahol az adatbázist folyamatosan kérdezni és írni kell.

Köszönöm a válaszokat előre is!
Tamás
‹ Karakter kódolás több weboldal esetében Jelszó "mysql nyelven" ›
 ■
1

Minél később

Poetro · 2011. Jan. 10. (H), 11.22
Minél később nyitod meg, és minél később zárod be annál jobb. Az egyik legköltségesebb művelet az adatbázis kapcsolat megnyitása. Ha ezt el tudod halasztani, az jó, mert addig is tudsz tartalmat kiírni a felhasználónak, így kevesebbet kell várnia, hogy valamit lásson. Valamint a megnyitott adatbázis kapcsolatot érdemes addig nyitva tartani, amíg csak lehet, ne kelljen esetleg az utolsó pillanatban újra megnyitni. Esetleg érdemes lehet elgondolkodni a prezisztens adatbázis kapcsolatokról, bár annak is megvannak a buktatói.
2

köszönöm

tomiie · 2011. Jan. 10. (H), 13.59
Köszönöm a válaszodat. Elolvastam az oldalt, amit linkeltél, de a folyamatos kapcsolat sajnos megáll ott, hogy a szolgáltatóm CGI segítségével fordítja a PHP-t, amiről azt írják, hogy minden oldal lefordítása után azonnal leáll, így a folyamatos kapcsolat emiatt ki van zárva. Mindenesetre jó erről is tudni, köszönöm, hogy belinkelted.

Hogyan szokás akkor egy nagyobb terhelésű oldal adatbázis kapcsolatát megoldani?
Smarty segítségével cache-elve van minden, hosszabb-rövidebb élettartammal, de így is sokszor van, hogy azonnal el kell tudni érni az adatbázist, emiatt továbbra is lehet rengeteg lekérés.

Érdekelne még, hogy egy óriástáblánál, amiben rengeteg bejegyzés van (akár milliós nagyságrendben) és ez össze van linkelve másik táblákkal, hogyan lehet hatékonyan összeadás, megszámolás műveleteket elvégezni anélkül, hogy akár egy percbe is teljen, mire elvégzi egyszer a műveletet? Akkor is lassú volt nekem, ha MEMORY volt a motor, ami tárolta.
3

Érdekelne még, hogy egy

Poetro · 2011. Jan. 10. (H), 14.24
Érdekelne még, hogy egy óriástáblánál, amiben rengeteg bejegyzés van (akár milliós nagyságrendben) és ez össze van linkelve másik táblákkal, hogyan lehet hatékonyan összeadás, megszámolás műveleteket elvégezni

Ilyen esetben szükség lehet esetleg denormalizálásra, azaz egyes adatok több helyen is lehet hogy elő kell hogy forduljanak, hogy optimálisan lehessen velük számolni. Amennyiben ez sem oldja meg a problémákat, akkor lehetséges még a számítások részeredményeit meghatározott időközönként előállítani, és egy ideiglenes táblában tárolni, ezzel könnyítve meg a további számolást. Persze ez nem minden rendszerben megoldható. Minél nagyobb az adatbázis annál valószínűtlenebbé válik a valós idejű adatbányászat.
8

Értem és köszönöm.

tomiie · 2011. Jan. 10. (H), 17.03
Értem és köszönöm. Mindenképpen hasznos megoldás lehet részeredményeket kiszámolni, ez eddig nem is jutott eszembe, de abszolút logikus.
A kapcsolat hosszáról esetleg van valami meglátásod?
4

hogyan lehet hatékonyan

kuka · 2011. Jan. 10. (H), 14.24
hogyan lehet hatékonyan összeadás, megszámolás műveleteket elvégezni anélkül, hogy akár egy percbe is teljen, mire elvégzi egyszer a műveletet?
Ez már az Adatbázisok fórumba tartozik. De ott sem kapsz sok segítséget ha nem mutatsz kódot.

(A select utasítást lehetőleg create table és példa insert társaságában kérjük, hogy ne nekünk kelljen reprodukálnunk az adatbázisod szerkezetét, ha segíteni akarunk.)
5

Fórumrovat javítva

Török Gábor · 2011. Jan. 10. (H), 14.28
Átmozgattam az Adatbázis rovatba.
6

Én inkább nem tettem volna,

kuka · 2011. Jan. 10. (H), 14.49
Én inkább nem tettem volna, mert az eredeti "Adatbázis kapcsolat hossza" kimondottan PHP téma. Legalábbis szerintem.
7

Az eredeti kérdésben nincs

Török Gábor · 2011. Jan. 10. (H), 15.58
Az eredeti kérdésben nincs utalás PHP-ra. Én úgy látom, hogy a téma kimondottan elméleti adatbázis specifikus, nem egy adott szerver oldali környezetre vonatkozik.
10

Eredetileg PHP lett volna,

tomiie · 2011. Jan. 10. (H), 17.09
Eredetileg PHP lett volna, igen, de köszönöm, hogy áttetted, mert valóban elméleti kérdés csak.
9

Természetesen nem kérem

tomiie · 2011. Jan. 10. (H), 17.06
Természetesen nem kérem, hogy Nektek kelljen kitalálni. Nem is ezt volt a téma tárgya. Viszont nem is konkrét kódot mutatnék, hanem általánosságban érdekelne a megoldás, például, hogy ki, mit és hogyan használ.
Az eredeti témával, az adatbázis-kommunikációval kapcsolatban van ötleted?