Håller på och skriver en applikation som använder SQLite.

Jag har tre tabeller enligt:

A:
ID
text

B:
ID
text

C:
AID
BID
count

I sql enforcas inte FOREIGN KEYS.

Jag kommer få kaskader av info. Det är en A.text, och en lista med B.text och count.
Till C lägger jag sen ett antal rader, alla med detta enda motsvarande AID, och övriga med Bid och count för varje i listan.

Typ:
A: apa
B | count
banan | 4
citron | 5

=> (apa har AID 1, banan BID 1 och citron BID 3) =>

A|B|count
1|1|4
1|3|5

Jag funderar nu helt enkelt om det finns något bättre sätt att lösa det på än att loopa igenom hela listan och ta fram BID för varje B.text. Observera att jag får det på "programmatisk form", det är alltså inget som finns i någon tabell redan innan.

Ideer?

Jag förstår inte vad du vill göra. Du får inga svar eftrsom du ställer så otydliga frågor.

Varför ska du lagra count() / dvs antal?

Det är inget bra, du kan ta fram det med select count()

Det är inte en count på det sättet, du kan se det som ett värde C.

Skit samma.
Jag har en lista med par; (x, y). x är en sträng, y är ett heltal (I en std::map<std::string, int> i C++ i mitt fall)
I en tabell (1) har jag x och ett id för varje sådant x. ("a", 1; "b", 2; ...)
I en annan tabell (2) har jag kopplingar till id:et i tabell 1. En kolumn med det id:et och en kolumn för "y" ovan.

Jag kan få in ("a", 7), vilket jag då vill omvandla till (1, 7) och infoga i tabell 2.

Det är pissenkelt. Det jag funderade på var om det finns bättre sätt att göra det på än att kolla varje enskilt x-värde i min input-lista, för att på så sätt få fram mitt x-id. Och eftersom det finns temporära tabeller är problemet löst.

INSERT INTO t2(idX, idY)
SELECT 7, t1.id from t1 where t1.x = 'a'
(t1.x ska vara unikt)

Jo, jo, det var det jag menade med "pissenkelt". Jag funderade på om det fanns andra sätt, 1k såna listor med 10k såna poster vill jag helst få iväg så fort det går.

Jag gissar att det går fortare att lägga in skiten i en temporär tabell, göra en join och lägga in allt i t2.

Styr du över tabellstrukturen själv?

I så fall skulle jag tycka att eftersom varje B har ett count och varje count bara hör till ett B, så skall de ligga i samma tabell. Det kunde se ut som:

A:
==
ID
A-text

B:
==
A-ID
B-text
Count


Om du nu inte vill ändra där, så skulle jag göra något i stil med:

Köra query "INSERT INTO A (Text) VALUES (@Text); SELECT @@IDENTITY", med parametern @Text.
Spara det returnerade ID-värdet som A-id.

För varje B:
Köra queryn "INSERT INTO B (Text) VALUES (@Text); SELECT @@IDENTITY", spara det returnerade B-ID:t.
Köra queryn "INSERT INTO C (AID, BID, Count) VALUES (@Aid, @Bid, @Count)"

HELST skulle jag ha kombinerat ihop de två senare till en SP, och bara haft ett anrop till SP:n. Men det är inte alltid kul att använda stored procedures.

/Göran

<b>>I så fall skulle jag tycka att eftersom varje B har ett count och varje count bara hör till ett B, så skall de ligga i samma tabell. Det kunde se ut som[...]</b>

Jo, så kan man göra, och jag har också övervägt det. Problemet är att det kommer göras "kombinationssökningar" på "b-text". Alltså; man söker på ett antal b samtidigt och kombinerar resultaten. Eftersom det är strängar, och eftersom det kan vara hyfsat stora datavolymer och hyfsat många samtidiga användare känns det bättre att bara söka på strängar en gång för varje fråga sen.

<b>>
För varje B:
Köra queryn "INSERT INTO B (Text) VALUES (@Text); SELECT @@IDENTITY", spara det returnerade B-ID:t.
Köra queryn "INSERT INTO C (AID, BID, Count) VALUES (@Aid, @Bid, @Count)"
</b>
Men varje B kommer förekomma flera gånger per varje A. Jag kan inte sätta in nya varje gång.

OK, så för varje B slår du först upp det i B-tabellen, och om det finns sätter du bara in B-ID:t i C-tabellen.

Om det inte finns sätter du in det i B-tabellen, noterar ID:t och sätter in detta i C-tabellen.

För visst sa du att du inte själv behöver hantera count-datat? Eller kommer du, då det finns flera av samma B på en A, vilja summera deras count-värden också?

<b>>OK, så för varje B slår du först upp det i B-tabellen, och om det finns sätter du bara in B-ID:t i C-tabellen.

Om det inte finns sätter du in det i B-tabellen, noterar ID:t och sätter in detta i C-tabellen.</b>
Precis.
Eller enklare; först kollar jag om B finns, finns det inte lägger jag in det. Sen slår jag upp det och lägger in det i tabellen.

Det jag funderade på var om det fanns effektivare sätt att lösa det på; det blir väldigt många databasanrop. Och lösningen är nu något i stil med:

CREATE TEMP TABLE t1(btext, c);
INSERT INTO t1(?, ?);
--mata på med hela min std::map in i t1.
INSERT INTO B
SELECT btext FROM B WHERE NOT btext IN (SELECT bID FROM B);
INSERT INTO C
SELECT bID, c FROM (t1 NATURAL JOIN B)

Skrivet på frihand, koden kan skilja sig lite. Jag misstänker att det är snabbare att göra så här; det blir ungefär hälften eller en tredjedel så många anrop till databasen, men precis samma logik.