Mockrat dekuji, table partitioning mi unikl. Oraclem nedisponuji, ale snad umi i PostgreSQL:
http://www.postgresql.org/docs/8.1/static/ddl-partitioning.html "Currently, PostgreSQL supports partitioning via table inheritance." Nastavenim vhodnych pravidel se muze zautomatizovat prevod dotazu z hlavni tabulky primo na dedici tabulky (ktere maji vlastni indexy). S pozdravem, Petr Gola On 6/11/06, Lukas Barton <[EMAIL PROTECTED]> wrote:
Petr Gola wrote: > Zdravim konferenci, > > tak jsem se nad tim trosku vic zamyslel. Nejprve proc jsem to tak > chtel. Zde jsou duvody pro rozdeleni do jednotlivych tabulek pro > kazdeho klienta (terminal): > > 1) bezpecnost - mozna vychazi z dob Foxky apod. starsich databazi, kdy > kazda tabulka byla jednim souborem. Proste jsem mel pocit, ze pri > poruseni integrity dat (ke kteremu by teoreticky nemelo nikdy dojit, > ze... ale...:) takhle system na chvili prijde jen o jednoho klienta > (nez se pripadne obnovi ze zalohy). Bezpecnot by mela resit 2 vrstva. Nikoliv DB, rozumna databaze by nemela mit problemy s porusenim integrity dusledkem vypadku. K tomu je prece C v ACID vlastnostech transakci. > > 2) efektivnost - mozna opet zastaraly nazor, ale rozdelenim na vice > tabulek jsem chtel dosahnout i vyssi efektivnosti prace s daty > tabulky. Kazdy den totiz budou pribyvat do tabulky stovky, mozna > tisice novych zaznamu (radku). Tim se dostavam k 3 duvodu... Toto resi napr. Oracle nebo MS SQL server resi pomoci "table partitioning". Na disku to pak mohou byt ruzne soubory. Behaji nad tim rychleji transakce, ktere pouzivaji jen jednu partition ... dalsi dusledky jsem moc nezkoumal, pouzili jsme to pri vyrobe extraktu produkcni databaze do "privatniho ODS" nasi aplikace (meli jsme vice verzi replik, jedna partion byla pro jednu repliku). PS: ted kdyz vidim, k cemu to chcete pouzit si take myslim, ze v dobe modernich databazi je to nesmysl.
