interesira me kad particioniram tabelu i kad kreiram index za kolonu koja je particionirana, da li se index za svaku particiju zapisuje posebno tj. kreira se zasebni index za svaku particiju?
Particioniranje tabele kod baza
Zaključano
Zakačeno
u kom rdbms-u ?
na mysql-u kolona po kojoj particionises tabelu mora biti deo primarnog kljuca, na nekim rdbms-ovima to nije tako, mozes da particionises po bilo kojoj koloni (mada efektivno ta kolona sama po sebi postane deo pk-a al to nije bitno)
sto se samog "zapisa na disk" tice, i to zavisi od baze do baze / storage engine-a do storage engone-a, ali generalno se particije tretiraju kao zasebne tabele te se svaki index snimao kao sto bi se snimao za zasebnu tabelu. obicno imas jedan uber index koji generalno cuva informacije gde je sta kod sistema koji daju mogucnos kompleksnog particionisanja. taj "uber" index ne postoji kod sistema koji imaju jednostavno particionisanje (posto se iz same definicije tabele moze lako doci do toga sta se u kojoj particiji nalazi)... takodje, ako particionises tabelu na pgsql-u proveri da li je ispravljen bag sa nasledjivanjem constraintsa-a od parent tabele, taj bug je dugo smarao ne znam dal je ispravljen, za mysql obrati paznju da teras najnoviji 5.1 posto u pre-ga i oko ga 5.1 partitioning management je radio pateticno (nisi mogao da checkiras samo jednu particiju i slicno) ... oracle, db2 i ekipa sljakaju 1/1 .. za m$sql nemam pojma kako se snalazi sa istim
na mysql-u kolona po kojoj particionises tabelu mora biti deo primarnog kljuca, na nekim rdbms-ovima to nije tako, mozes da particionises po bilo kojoj koloni (mada efektivno ta kolona sama po sebi postane deo pk-a al to nije bitno)
sto se samog "zapisa na disk" tice, i to zavisi od baze do baze / storage engine-a do storage engone-a, ali generalno se particije tretiraju kao zasebne tabele te se svaki index snimao kao sto bi se snimao za zasebnu tabelu. obicno imas jedan uber index koji generalno cuva informacije gde je sta kod sistema koji daju mogucnos kompleksnog particionisanja. taj "uber" index ne postoji kod sistema koji imaju jednostavno particionisanje (posto se iz same definicije tabele moze lako doci do toga sta se u kojoj particiji nalazi)... takodje, ako particionises tabelu na pgsql-u proveri da li je ispravljen bag sa nasledjivanjem constraintsa-a od parent tabele, taj bug je dugo smarao ne znam dal je ispravljen, za mysql obrati paznju da teras najnoviji 5.1 posto u pre-ga i oko ga 5.1 partitioning management je radio pateticno (nisi mogao da checkiras samo jednu particiju i slicno) ... oracle, db2 i ekipa sljakaju 1/1 .. za m$sql nemam pojma kako se snalazi sa istim
Potpis
imam jednu InnoDB tabelu u kojoj ima kolona `status`. ti (workflow) statusi se menjaju tokom life-cycle entiteta da bi na kraju postali `processed` posle toga skoro nikad vise ne menjaju status (ostaju `processed`).
status nikako nije deo primarnog kljuca, jedino sto bi mogao da bude deo nekog unique kljuca. statusa moze da bude 15-ak i definisani su u kodu (enumerator).
primarni kljuc tabele je autoincrement. colona `status` je varchar(20).
pitanje: da li je moguce isprarticionisati tabelu tako da u jednoj particiji budu samo zapisi sa statusom `processed` a u drugoj svi ostali zapisi?
status nikako nije deo primarnog kljuca, jedino sto bi mogao da bude deo nekog unique kljuca. statusa moze da bude 15-ak i definisani su u kodu (enumerator).
primarni kljuc tabele je autoincrement. colona `status` je varchar(20).
pitanje: da li je moguce isprarticionisati tabelu tako da u jednoj particiji budu samo zapisi sa statusom `processed` a u drugoj svi ostali zapisi?
Potpis
Acta, non verba!