[MS-SQL/SP] van/ tot overzicht

[Verwijderd]

Hallo,
Hele dag bezig met probleem en ik kom er niet uit. Welke MS-SQL guru kan me helpen:

Ik heb de volgende tabel:

code:

Persoon   |   datum   |    Status
---------------------------------------
1              |   1-1-4    |  Ziek
1              |   2-1-4    |  Ziek
1              |   3-1-4    |  Ziek
1              |   4-1-4    |  Werkt
1              |   5-1-4    |  Ziek
1              |   6-1-4    |  Ziek
1              |   7-1-4    |  werkt
1              |   8-1-4    |  werkt
1              |   9-1-4    |  werkt

Nu wil ik graag het volgende overzicht:

code:

persoon   |   van   |   tot    | status
---------------------------------------------\
1              | 1-1-4  | 3-1-4 | Ziek
1              | 4-1-4  | 4-1-4 | Werkt
1              | 5-1-4  | 6-1-4 | Ziek
1              | 7-1-4  | 9-1-4 | Werkt

Kan iemand me vertellen hoe ik dat kan krijgen?
In SQL of in StoredProcedures/triggers?

PLEASE help

[watzie]

Weet je echt HEEL zeker dat je dit in SQL wil gaan oplossen?
Dat is namelijk echt superduur (en ik hoop dat je weet wat 'duur' betekent). Zekers als je een paar dagjes voor een paar mensen logt...

Doe het lekker in je (niet sql) code, da's eenvoudiger en sneller. Met sql proberen op te lossen is hoogstens een 'academische oefening'. Je kunt hier niks voor maken waar je in de praktijk iets aan hebt.

Als je echter toch perse iets in sql wil flansen dan zul je je tabellen moeten wijzigen, of tabellen erbij, of allebei om het makkelijker te maken.

[ Voor 7% gewijzigd door watzie op 27-07-2004 13:50 . Reden: semantische fout ]

[LuCarD]

watzie schreef op 27 juli 2004 @ 13:49:
Weet je echt HEEL zeker dat je dit in SQL wil gaan oplossen?
Dat is namelijk echt superduur (en ik hoop dat je weet wat 'duur' betekent). Zekers als je een paar dagjes voor een paar mensen logt...

Duur?
Hij heeft toch al een database en wil alleen een bestaande functionaliteit uitbreiden?
Dus wat betekent duur in jouw idee?

Doe het lekker in je (niet sql) code, da's eenvoudiger en sneller. Met sql proberen op te lossen is hoogstens een 'academische oefening'. Je kunt hier niks voor maken waar je in de praktijk iets aan hebt.

???

Als je echter toch perse iets in sql wil flansen dan zul je je tabellen moeten wijzigen, of tabellen erbij, of allebei om het makkelijker te maken.

tabellen er bij is een optie.

code:

// Pseudo code 
1/ maak een selectie gesorteerd op persoon en datum 
2/ Loop door de selectie 
2.1/ sla de start datum van ziek zijn op
2.2/ als persoon niet meer ziek dan is de waarde die je opgeslagen hebt in 2.3 de eind datum van ziek zijn
en sla dat resultaat op in een 'tijdelijke tabel' 
2.3/ bewaar huidige datum van de rij
3/ maak een selectie op de tijdelijke tabel  van punt 2.2 en geef het resultaat terug.

[ Voor 4% gewijzigd door LuCarD op 27-07-2004 14:00 ]

[watzie]

LuCarD schreef op 27 juli 2004 @ 13:59:
Duur?
Dus wat betekent duur in jouw idee?

Ik vroeg het natuurlijk aan TS maar goed, wil het jou ook nog wel uitleggen:
Duur betekent dat het veel tijd kost om uit te voeren, en/of veel resources kost en/of....
Dit is officieel algemeen bekend spraakgebruik onder professionele IT'ers dus het is niet 'mijn idee' om het woord duur te gebruiken.

In deze context betekent het dus dat de oplossing waar TS expliciet om vraagt dusdanig slechte performance zal hebben dat het niet de moeite van het proberen waard is.

[LuCarD]

watzie schreef op 27 juli 2004 @ 14:11:
[...]

Ik vroeg het natuurlijk aan TS maar goed, wil het jou ook nog wel uitleggen:
Duur betekent dat het veel tijd kost om uit te voeren, en/of veel resources kost en/of....
Dit is officieel algemeen bekend spraakgebruik onder professionele IT'ers dus het is niet 'mijn idee' om het woord duur te gebruiken.

Maar als 'professionele IT-er' moet je toch ook weten dat je zonder een complete overzicht niet goed kan beoordelen of iets 'duur' kost of niet. Misschien heeft de TS maar 50 medewerkers, en een gigantisch cluster draaien. Of misschien wil hij het alleen in Batch draaien 1 keer per maand.

In deze context betekent het dus dat de oplossing waar TS expliciet om vraagt dusdanig slechte performance zal hebben dat het niet de moeite van het proberen waard is.

Niet de moeite waard om te proberen?????

Op basis van welke gegevens kom jij tot deze conclusie?

[curry684]

Dit geval komt vaag bekend voor uit "The Guru's Guide to Transact-SQL Programming" en is wel redelijk getikt complex ja: en ik moet ook toegeven dat het in T-SQL niet de handigste manier is om te doen Zal eens opzoeken vanavond als ik eraan denk.

Notwithstanding that is het met een cursor natuurlijk peanuts, maar ik geloof dat het ook zonder kan.

[Vaudtje]

LuCarD schreef op 27 juli 2004 @ 14:18:
[...]


Maar als 'professionele IT-er' moet je toch ook weten dat je zonder een complete overzicht niet goed kan beoordelen of iets 'duur' kost of niet. Misschien heeft de TS maar 50 medewerkers, en een gigantisch cluster draaien. Of misschien wil hij het alleen in Batch draaien 1 keer per maand.


[...]

Niet de moeite waard om te proberen?????

Op basis van welke gegevens kom jij tot deze conclusie?

Hoewel aannames inderdaad meestal fataal zijn, mag er toch wel vanuit gegaan worden dat er een optimalere oplossing is te vinden voor het probleem van TS, dan het volledig in SQL uit te voeren (Vandaar dat Curry het 'redelijk getikt complex' noemt).
Als je van tevoren weet dat je oplossing te debiel voor woorden is, dan is het inderdaad niet de moeite van het proberen waard !!!1!!!!!

[ Voor 6% gewijzigd door Vaudtje op 27-07-2004 14:58 ]

[curry684]

Vaudtje schreef op 27 juli 2004 @ 14:57:
[...]

Hoewel aannames inderdaad meestal fataal zijn, mag er toch wel vanuit gegaan worden dat er een optimalere oplossing is te vinden voor het probleem van TS, dan het volledig in SQL uit te voeren (Vandaar dat Curry het 'redelijk getikt complex' noemt).
Als je van tevoren weet dat je oplossing te debiel voor woorden is, dan is het inderdaad niet de moeite van het proberen waard !!!1!!!!!

Uhm ja maar ik vermeld er ook in dezelfde adem bij dat het met een cursor dodelijk simpel is

[edit]
Naja dodelijk simpel is een 2e, maar okee:

SQL:

CREATE TABLE #temp (
    Persoon int,
    BeginDatum datetime,
    EindDatum datetime,
    Status varchar(32)
    );

DECLARE @stat varchar(32), @oldstat varchar(32), @persoon int;
DECLARE @begin datetime, @datum datetime;

DECLARE crs CURSOR FOR
SELECT Persoon, Datum, Status
FROM Timesheet
ORDER BY Persoon, Datum;

OPEN crs;
FETCH NEXT FROM crs
INTO @persoon, @datum, @stat;
WHILE @@FETCH_STATUS = 0
BEGIN
    IF @stat <> @oldstat OR @oldstat IS NULL
    BEGIN
        IF @oldstat IS NOT NULL 
            INSERT INTO #temp 
            VALUES (@persoon, @begin, @datum - 1, @oldstat);    
        SET @begin = @datum;
    END

    SET @oldstat = @stat;
    FETCH NEXT FROM crs
    INTO @persoon, @datum, @stat;
END
INSERT INTO #temp VALUES (@persoon, @begin, @datum, @oldstat);  
CLOSE crs;
DEALLOCATE crs;

SELECT * FROM #temp;
DROP TABLE #temp;

Hij werkt wel

* curry684 kruipt weer snel weg achter 'cursors zijn ondingen en moet je nooit gebruiken'

[ Voor 47% gewijzigd door curry684 op 27-07-2004 15:22 ]

[Infinitive]

Op zich zie ik een 'table scan' niet echt als een probleem wat betreft performance. Als het aantal gebruikers en aantal geregistreerde dagen te groot wordt, kan je een cache tabel bijgehouden, zodat je alleen naar nieuwe records en de laatste, niet afgesloten, periode hoeft te kijken. Eventueel kan je de cache tabel bijwerken op het moment van inserten in je oorspronkelijke tabel.

Of denk ik te eenvoudig?
Ik zou ook geen snellere manier weten tenzij je misschien je oorspronkelijke tabel gaat aanpassen...

[ Voor 22% gewijzigd door Infinitive op 27-07-2004 15:27 . Reden: ik edit altijd bijna al mijn posts. ]

[SuperRembo]

Ah, leuke oefening

SQL:

SELECT e.EmployeeID, e.Name, sub.Status, MIN(sub.DateCreated) AS DateFrom, MAX(sl3.DateCreated) AS DateTo
FROM (
    SELECT sl1.StatusLogID, sl1.EmployeeID, sl1.Status, sl1.DateCreated, MIN(sl2.DateCreated) AS DateCreated2
    FROM StatusLog sl1 
    INNER JOIN StatusLog sl2 ON sl1.Status <> sl2.Status AND sl1.DateCreated < sl2.DateCreated AND sl1.EmployeeID = sl2.EmployeeID
    GROUP BY sl1.StatusLogID, sl1.EmployeeID, sl1.Status, sl1.DateCreated
) sub 
INNER JOIN StatusLog sl3 ON sub.EmployeeID = sl3.EmployeeID AND sub.Status = sl3.Status AND sub.DateCreated2 > sl3.DateCreated
INNER JOIN Employees e ON sub.EmployeeID = e.EmployeeID
GROUP BY e.EmployeeID, e.Name, sub.Status, sub.DateCreated2
ORDER BY MIN(sub.DateCreated), sub.DateCreated2

Hij pakt alleen de laatste regel niet, omdat daar geen volgende status bij bestaat

code:

Emp.Name Status DateFrom   DateTo
1   Jan  Ziek   01-01-2004 03-01-2004
1   Jan  Werkt  04-01-2004 04-01-2004
1   Jan  Ziek   05-01-2004 06-01-2004

[Verwijderd]

jongens!

Ik moet helaas de trein pakken, maar ik kijk er thuis meteen naar!!!

Super bedankt!!!!