SQL-knåp

Går väl att lösa med en GROUP BY..
Men behöver nog egenteligen lite mer information..
Vad är primary key för tabellen?
Har datumen bättre upplösning?
Tillåter du att man lägger in saker retroaktivt, dvs. får du lägga in en händelse för en artikel med ett tidigare datum än den senaste händelsen för artikeln?

Tanken är iaf att du grupperar ihop artiklarna och hämtar ut någon sorts unik identifierare för den senaste artiklen (såsom ett högsta id, eller ett högsta datum), och sedan använder denna identifierare när du söker efter saldo=0 i en ny query.

"Pseudo-kod" lösning om bättre upplösning på datum (eller endast en händelse per artikel per datum):
SELECT artikel,saldo FROM tbl as t1 JOIN (SELECT artikel,max(datum) FROM tbl GROUP BY artikel LIMIT 1) as t2 ON t1.artikel = t2.artikel AND t1.datum=t2.datum WHERE t1.saldo='0'

"Pseudo-kod" lösning om icke-retroaktiva händelser med primary key autoincrement kolumn "id":
SELECT artikel,saldo FROM tbl as t1 JOIN (SELECT max(id) FROM tbl GROUP BY artikel LIMIT 1) as t2 ON t1.id = t2.id WHERE t1.saldo='0'

Hej,

Om jag tolkade din fråga rätt så borde något i stil med detta lösa din fråga

select artikel from produkt group by artikel having sum(saldo) = 0

//C

Om du inte har några framtida datum lagrade i databasen (och självklart datumen lagrade i ett datumformat) så borde detta ge dig det du söker

select artikel, max(datum) from produkt group by artikel having sum(saldo) = 0

//C

Säker på att du testat ordentligt där?
Den bör ju rimligen säga att du har något i lager sålänge som du någon gång i tiden har haft det i lager, även om saldo=0 just nu.
Dvs.

BIL1             20110515          inkom             A               0
BIL1             20110711          flyttad           B               0
BIL1             20110901          inventerad        B               1
BIL1             20110902          leverans          B               0

Får ju sum(saldo) till 1, varav "having sum(saldo)" inte är 0.

Kanske missförstått din användning av saldo dock..

Okej det förklarar saken, jag hade missförstått saldo alltså.
Då håller jag med om att having sum(saldo)=0 är ett bra val (går nog att göra mer effektivt genom att bygga om den så att den inte behöver gå igenom alla saldo-rader för summering dock, men gissar att prestanda på SQL-frågan inte är något problem nu heller)

Hmm, så det är endast artiklar som är äldre än 1 år som är intressanta i frågan?
Eller använder du fortfarande de som inte är äldre än ett år på något sätt från svaret?
(Annars, lägg till ett extra vilkor för HAVING där du kollar att max datumet är inom ett år)

Kör du din backup mot en annan tabell, eller sparar du det på något annat sätt?
(Annars, slå ihop en INSERT med din SELECT, och skippa mellansteget att hämta ut det till din programkod)

Är 30sekunder ett problem, eller är det en okej körtid för ditt ändamål?
(Är det ens värt att försöka optimera?)

Har du ett index på saldo? Om inte, skriver du till saldo väldigt ofta, eller kan du tänka dig att bygga ett index?
(Index på saldo skulle kunna göra allt väldigt mycket snabbare för läsning, men att underhålla ett extra index innebär ju lite långsammare skrivning)

Vilken databas använder du? (mysql, postgresql, mssql, ..)
(Bra att veta bara)

Det stämmer att man inte ska använda för många index, eftersom de kostar att underhålla dem, men det är en avvägning över hur mycket prestanda de ger.
Om dina tabeller sällan uppdateras så kan du använda index utan att tänka, men uppdateras dem ofta (insert/delete/update) så kan kostnaden bli för hög.

Har ingen tidigare erfarenhet av MSSQL, så detta blir otestat, men borde väl stämma någolunda:

SELECT artikel FROM produkt GROUP BY artikel HAVING max(saldo)=0 AND datediff(year,max(datum),getdate())>0

Detta borde alltså ge dig alla artiklar som är slut och som inte uppdaterats på över ett år. (Men ville du att alla artiklar, oavsätt om de var slut eller inte, skulle hittas baserat på datumet? Isf skippa max(saldo)=0 delen)

Bytte ut sum(saldo)=0 mot max(saldo)=0 eftersom max inte behöver gå igenom alla värden, såfort den hittar en 1:a så kan den sluta (sum måste fortsätta och beräkna summan eftersom den "kan" komma ett negativt tal, om du inte använder någon icke-negativ datatyp och SQL parsern är tillräckligt smart vid optimeringen).

Du kan sedan använda ovanstående query som subquery för att läsa ut alla transaktioner också:

SELECT * FROM produkt WHERE artikel in (SELECT artikel FROM produkt GROUP BY artikel HAVING max(saldo)=0 AND datediff(year,max(datum),getdate())>0) as t2

Och du kan sedan använda ovanstående för att skapa en INSERT för insättning i din backup-tabell, enligt:

INSERT INTO annan_tabell(artikel,datum,händelse,lagerhylla, saldo) (SELECT artikel,datum,händelse,lagerhylla,saldo FROM produkt WHERE artikel in (SELECT artikel FROM produkt GROUP BY artikel HAVING max(saldo)=0 AND datediff(year,max(datum),getdate())>0) as t2) as t3

Det som saknas då är att köra en avslutande DELETE i produkt-tabellen på artiklarna du kopierade till annan_tabell:

DELETE FROM produkt WHERE artikel in (SELECT artikel FROM produkt GROUP BY artikel HAVING max(saldo)=0 AND datediff(year,max(datum),getdate())>0) as t2

Har ingen MSSQL att testa emot, så har säkert missat paranteser och sånt, och koden är ju otestad så kör inte någon av INSERT/DELETE frågorna på data som är viktig.

1) Hämta produkter som inte är i lager, notera när den senaste transaktionen inträffade.
2) Hämta ut alla transaktioner för produkterna som hittades ovan vars transaktionsdatum är äldre än ett år sedan den senaste transaktionen för produkten?

Är så du vill göra alltså? (det verkar ju som att du hämtade artiklarna för att få reda på transaktionerna)

Lättaste vore väl isf att hämta ut produkterna med HAVING max(saldo)=0 som tidigare, sedan joina ihop artikel och max(datum) med alla rader i tabellen (så varje artikel transaktion vet max-datum på sin senaste transaktion), och sedan bara filtrera ut resulatet med en WHERE..

Nått i stil med följande alltså:
SELECT * FROM produkt as t1 JOIN (SELECT artikel,max(datum) as maxdatum FROM produkt GROUP BY artikel HAVING max(saldo)=0) as t2 ON t1.artikel=t2.artikel WHERE datediff(year,datum,maxdatum)>0

Om det faktiskt bara är artiklarna som du var intresserade av så kan du ju då här bara gruppera på artikel igen, enligt:
SELECT artikel FROM produkt as t1 JOIN (SELECT artikel,max(datum) as maxdatum FROM produkt GROUP BY artikel HAVING max(saldo)=0) as t2 ON t1.artikel=t2.artikel WHERE datediff(year,datum,maxdatum)>0 GROUP BY artikel

Om den blir seg så skulle nog ett index på artikel kunna hjälpa en del iom. att vi joinar på artikel (visst dock att index blir dyra i ditt fall, så det beror väl på hur ofta du tänkt köra queryn)

Hmm okej, datediff kanske inte fungerar som jag trott, lite svårt att veta när man inte testat.. Kanske fungerar bättre att kolla mot dagar:

SELECT * FROM produkt as t1 JOIN (SELECT artikel,max(datum) as maxdatum FROM produkt GROUP BY artikel HAVING max(saldo)=0) as t2 ON t1.artikel=t2.artikel WHERE datediff(day,datum,maxdatum)>365

Annars så tycker jag att queryn ser rätt ut, den där borde ju hämta ut alla transaktioner som är 1år äldre än den senaste transaktionen för varje artikel som inte finns i lager.. Förutsatt att du inte har några datum från framtiden så borde det ju fungera som du vill alltså.
Hur ser maxdatum och datum kolumnerna ut för de rader som blir fel?

Hej igen,

Vill du vara väldigt high-tech så kan du ju göra utdraget och deleten i samma svep. Du kan nämligen få DELETE att även producera output om man säger som så.

Här är två referenser:
http://msdn.microsoft.com/en-us/library/ms189835.aspx
http://msdn.microsoft.com/en-us/library/ms177564.aspx

Här är ett förenklat exempel från en av sidorna.

DELETE Sales.ShoppingCartItem
    OUTPUT DELETED.*;

En av nackdelarna att göra på detta viset är att det är databasmotorspecifikt. Det är alltså mer portabelt att göra dessa två operationer i två svep i en transaktion (utdrag av data och sedan borttag).

//C