mysql problem sa id poljem

[Anakin14]

Ovako, imam bazu kojoj pristupa dosta klijenata u isto vreme, i koristio sam auto increament polje da bi bez problema postavio ID svakog row-a bez da citam svaki put max value iz id-a i rizikujem da neki klijent vec postavi taj id i dodatno komplikujem stvari.

E sada sam zbog performansa podelio tabelu na table_rad i table_rad_temp gde u danasnjem danu upisujem u temp tabelu i na kraju rada svakog klijenta njegova polja prabacujem u glavnu tabelu. Ovo sam uradio jer mi je dosta citanja za dasanji dan, a manje za arhivu.

E sada se stvorila poterba za rad_meta tabelom, ali je problem sledeci, ID-ovi stvoreni autoincreament poljem u temp tabeli nisu isti jer kada mysql prebaci u glavnu tabelu on za ta polja kreira nove auto increament vrendosti.

Jedno resenje je ono koje sam i hteo da izbegnem a to je da mi kod generise ID za svaku transakciju pa da lockujem tabelu na svakom pisanju itd ali to zelim da izbegnem

Mozda je jedno od resenja da u glavnu/temp tabelu ubacim row metaid, pa da za one redove kojima je potreban meta generisem neki metaid na osnovu drugih parametara iz tog reda, ali opet to je jedan dodatni column koji opet nece biti potreban za sve redove.

U sustini kada se upisuje u dnenvu tabelu sve je u redu, jer meta field dobija autoincreament id ali je problem na kraju dana kada transakcija kopira sve u glavnu tabelu i brise iz dnevne.

Da li je mozda najbolje resenje da ubacim denormalizovana polja, pa da imam null vrednosti?

[mileusna]

Pa u toj glavnoj tabeli izbaci da je ID autoincrement, već koristi ID koji si dobio u temp tabeli. Temp tabelu briši sa DELETE FROM table_rad_temp jer se tako zadržava autoincrement broj za razliku od TRUNCATE koji inicijalizuje i autoincrement na nulu. Tako će svi redovi u table_rad imati jedinstveni ID.

E sada sam zbog performansa podelio tabelu na table_rad i table_rad_temp gde u danasnjem danu upisujem u temp tabelu i na kraju rada svakog klijenta njegova polja prabacujem u glavnu tabelu. Ovo sam uradio jer mi je dosta citanja za dasanji dan, a manje za arhivu.

Sve zavisi od problema do problema, ne postoji jedinstveno rešenje za sve, ali možda možeš da probaš da "obrneš" rešenje? Da sve upisuješ u glavnu tabelu a da periodično (ili na svaki unos, zavisi koliko ih ima) kreiraš u temp tabelu današnje unose za čitanje. Zavisno od obima podataka, tabela onda može biti i tipa MEMORY što bi umnogome poboljšalo i performanse.

Jel koristiš InnoDB?

[Anakin14]

Interesantno mi je resenje:

pri unosu upisujem u glavnu tabelu i temp tabelu
pri promeni dana samo brisem iz temp tabele

mislim da je cak i bolje od

pri unosu upisujem u temp
pri promeni dana kopiram iz temp u glavnu, pa brisem iz temp

mada posto ima dosta write-a, to je za svaki unos dodatni insert, pa bas i nisam siguran koliko je bolje.
Sta bi ste vi uradili?

Inace posto ta temp tabela moze da ima i par desetina megabajta interesuje me da li ce toliko i trositi RAM-a pri MEMORY engine, npr ako tabela ima 20mb toliko ce i koristiti dodatnog rama. Da li se samo napravi MEMORY tabela i sve je isto ili postoji neka posebna logika rada sa njom?

[Anakin14]

da innodb