MySQL typ: update/replace if row not exist then insert

[sodjan]

> Det enda du behöver göra är att utöka tabellen med ett fält till,

Varför det ? Slav+Register är redan unikt.
Varför ett extra autoincrent fält och varför indexera på det ?
Jag ser inte alls hur det hjälper i detta fall...

[Barry_Lyndon]

Nä, jag var ute och cyklade, editerade mitt inlägg efter att du postat...
/Andreas

[sodjan]

OK, då är jag med...
Det rimliga vore ett unikt index på Slav+Register.
Sedan, om man ska göra INSERT först (och UPDATE om INSERT går fel)
eller tvärtom, beror enbart på vilket som kommer att "missa" oftast (men
båda alternativen "fungerar").

[Wise]

Det rimliga vore ett unikt index på Slav+Register.

Här var det min okunnskap som spelade mig ett spratt... Du nämde ju detta förut, fast jag var bensäker att det inte gick att kombinera två kolumner till ett unikt index...stupid me. Kollade upp detta lite mer och då löste sig allt. Typ såhär:

Kod: Markera allt

INSERT INTO table ... SELECT FROM ... ON DUPLICATE INDEX UPDATE ...

med nestlade SELECT's, blev en 600tecken lång SQL query tillslut

Tack alla för hjälpen

Föresten, när man har index på en tabell i MEMORY, vart hamnar indexinformationen? I minnet eller på disken? Rimligtvis i minnet, men hittar inget om det just nu i manualen till MySQL.

[sodjan]

Aha, OK. Att ha nycklar från flera fält är nog ganska "basic" i de flesta databaser...

Styr du "in memory" per tabell ? I så fall borde det finnas samma syntax för indexen, kan man tycka.
Eller styr du "in memory" per databas ? I så fall borde indexen hamna där resten av databasen ligger.
Vad händer med in-memory tabellen när systemet tas ner ?

[Wise]

Jag väljer hur varje tabell i en databas ska "drivas", så ungefär hälften av tabellernaa i samma databasen är MyISAM(disk) och hälften är MEMORY i mitt fall. När servern startas om så finns MEMORY tabellerna kvar, men de är tomma på rader. De behåller alla rader så länge servern är uppe, ej klientberoende.