Håber i kan se idéen i det. Altså har et unikt ID, som man jo normalt har når der ikke er andet unikt. Og så har jeg et ejer id som kan fremkomme igen og igen. Der er så bilag til hver ejer id, og disse er unikke for hver ejer.
Mit spørgsmål er så: Når jeg skal lave en insert, så skal jeg finde ud af hvad det næste bilag id vil blive, og det kan jo gøres med noget select count og where ejer id=[ejer id]. Er dette effektivt nok, eller er der en anden måde?
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
arne_v-> er lidt i tvivl om din løsning... Når en "ejer" der har 2 bilag i forvejen, laver et bilag skal det blive nr. 3. Med din løsning, vil det så ikke blive nr. 5 hvis nu en anden ejer også har 2 bilag?
Der er ikke en indbygget database funktion, som finder et specifikt id set sammen med et andet id. Jeg mener, det kan da umuligt kun være mig der har denne problemstilling?
Jeg tror at du skal have en multi sequence tabel saa.
ejer ---- ejerid, PK, auto ...
bilag ----- ejerid, PK, FK bilagid, PK ...
multiseq -------- ejerid, PK, FK currbilagid
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION SELECT currbilagid FROM multiseq UPDATE multiseq SET currbilagid = currbilagid INSERT bilag COMMIT
ja altså noget i retningen af: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION SELECT currbilagid FROM multiseq UPDATE multiseq SET currbilagid = currbilagid + 1 INSERT bilag (bilagid) values (currbilagid) COMMIT
Jeg kommer lige i tanke om. Du behoever ikke SERIALIZABLE. REPEATABLE READ er nok. Det er saadan set hele grunden til at jeg foreslog den separate tabel fremfor SELECT MAX+1.
Eriks løsning er meget tæt op min. Hans ejer.maxbilagid svarer til min multiseq.currbilagid - forskellen er at jeg har brugt en separat tabel mens han bare har brugt ejer tabellen.
Hvorfor har jeg lavet den separate tabel ? Godt spørgsmål - jeg er ikke i tvivl om at jeg selv ville lave det med separat tabel. Men argumenterne er lidt luftige. Jeg vil helst have at ejer tabellen er en model af ejers faktiske egenskaber, mens det største bilags id er en ren teknisk utility ting.
Med hensyn til SQLServer specifikke muligheder, så fandt jeg noget gammelt kode med:
BEGIN SELECT f FROM t WITH (TABLOCKX) WHERE id = ? UPDATE t SET f = ? WHERE id = ? COMMIT
Jeg tror at et lavt transaction isolation level kombineret med WITH (TABLOCKX) på den SELECT vil virke lige så godt som transaction isolation level read repeatable på SQLServer.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
