[OT] Cijena DB operacija unosa/azuriranja podataka koji ne moraju biti uvijek razliciti

[Bubba]

Pozdrav svima,

ispricavam se na OT-u, ali znam da ovdje povremeno oko bace i SQL starci,
pa bih cjenio misljenje. hcp.baze je poprilicno mrtva, ali stavljam tamo
cross uz FuT na hco.l.

Naime kaj, imam situaciju gdje bi u jednu tabelu veliki broj klijenata
(100k +, recimo) trebao upisivati odredjene podatke u nekim kratkim
intervalima, tipa svakih 60 sekundi. Ti podatci nekada mogu biti
istovjetni onima koji su vec u bazi a nekada se mogu promijeniti.
Takodjer, "stari" podataka, odnosno onaj koji je razlicit od aktualnog, mi
nije bitan tj. nemam ga potrebu cuvati.

Tabela je poprilicno jednostavna, ima PK, FK id-a klijenta i 10ak ostalih
polja (dio tipa int, nesto boolova i teksta).

E sad, koliko ja vidim (nota bene - nesam skolovala SQL u neslucenim
dubinama), imam nekoliko opcija:

a) jednostavno lupam INSERT i sporadicno okinem nekakvo "ciscenje" baze u
vidu DELETE "starih/istih" unosa
b) trazim redak po klijentu i provjeravam jesu li mu polja jednaka kao
aktualnom koji bi se trebao zapisati, pa ovisno o tome napravim UPDATE ili
nista
c) koristim nekakav hash? Radi se o Microsoft SQL-u (iako je podlozno
promjeni po potrebi) pa ili zapisujem u dodatnu kolonu hash vrijednsot tog
retka kojeg mijenjam ako se razlikuju, ili postoji neka SQL funkcija koja
mi to moze olaksati?

Postoji li nekakva uvrjezena praksa za ovakve slucajeve? Je li jeftiniji
INSERT bez kontrole pa onda DELETE kada bude prilike (najmanji load ili
nesto slicno), odnosno kosta li takva opcija manje od SELECT + UPDATE ako
velicina baze ne igra ulogu (u smislu novca)? Postoje li neki eksterni
mehanizmi (tipa ova hash ideja ili nesto slicno) cime bi se tome moglo
doskociti?

TIA!

--
"If you lie to the compiler,
it will get its revenge."
Henry Spencer
http://www.pci-z.com/