Raws into Columns additionaly goruped by one column

Cześć,

chciałbym uzyskać Table 2 z Table 1.
Czy mogę prosić o jakieś wskazówki jak się do tego najlepiej zabrać?

Pozdrawiam,
A.

**Table 1 **

Case ErrorCode Date
1 A 2018-01-25
1 B 2018-01-15
1 C 2018-01-15
1 A 2018-01-15
1 D 2018-01-15
1 A 2018-01-15
2 D 2018-01-26
2 A 2018-01-26
2 D 2018-01-25
2 D 2018-01-24
2 C 2018-01-24

**Table 2 **
Case Date ErrorCode
1 2018-01-25 A
1 2018-01-15 B / C / A / D A
2 2018-01-26 D / A
2 2018-01-25 D
2 2018-01-24 D / C

W starszych wersjach XML + STUFF natomiast w SQL Server 2017+ and SQL Azure: STRING_AGG

DECLARE @table1 TABLE
(
   [Case] INT,
   ErrorCode CHAR(1),
   [Date] DATETIME
);

INSERT INTO @table1
VALUES
(1, 'A', '2018-01-25'),
(1, 'B', '2018-01-15'),
(1, 'C', '2018-01-15'),
(1, 'A', '2018-01-15'),
(1, 'D', '2018-01-15'),
(1, 'A', '2018-01-15'),
(2, 'D', '2018-01-26'),
(2, 'A', '2018-01-26'),
(2, 'D', '2018-01-25'),
(2, 'D', '2018-01-24'),
(2, 'C', '2018-01-24');

SELECT *
FROM @table1;

SELECT tabel2.[Case],
      tabel2.[Date],
      STUFF(
      (
          SELECT ', ' + ErrorCode
          FROM @table1 t1
          WHERE t1.[Case] = tabel2.[Case]
                AND t1.[Date] = tabel2.[Date]
          FOR XML PATH('')
      ),
      1,
      1,
      ''
           ) AS [ErrorCode]
FROM
(SELECT DISTINCT [Case], [Date] FROM @table1) AS tabel2
ORDER BY tabel2.[Case],
        tabel2.[Date];

Dziękuję, właśnie poszedłem w STUFF / FOR XML PATH i zwraca oczekiwane wyniki bardzo ładnie ale chodzi koszmarnie wolno: dla 100 rekordów zwraca wynik w 10 sekund, dla 200 już w 40 sekund a dla 300 w 90 sekund,
A rekordów do przemielenia mam około 70 tys... Obawiam się, że nie uda mi się doczekać na wyniki:)
Czy można tu coś zoptymalizować?

A może kursory (osobiście nie używałem, niektórzy chwalą)?

Jestem początkujący w temacie dlatego dopytuję. Rozumiem jednak, że nie polecasz kursorów?

Na tosterze masz ten serwer sqla? 3 miliony wierszy

Hmm... server gdzieś u zachodnich sąsiadów:) Czyli nie jest to normalne, że tak mi mieli? A może to zależeć od konkretnej zawartości uzyanych komórek czy nie powinno? Nie mam tak jednak cudów w mojej ocenie.

arhetyp napisał(a):

A może to zależeć od konkretnej zawartości uzyanych komórek czy nie powinno?

bingo, dane ktore tam siedza maja znacznie ;)

tym razem 3 miliony wygenerowalem przy pomocy scryptu ponizej i tu juz znacznie wolniej ale nie jest tak tragicznie jak u ciebie ;)

DECLARE @i BIGINT;
SET @i = 0;

WHILE @i < 3000000
BEGIN
    INSERT INTO dbo.table1
    SELECT CAST(RAND() * (10000 - 1) + 1 AS INT),
           CHAR(CAST((69 - 65) * RAND() + 65 AS INTEGER)),
           DATEADD(DAY, CAST(RAND() * 10000 AS INT) % DATEDIFF(DAY, '2018-01-01', '2019-01-01'), '2018-01-01');
    SET @i = @i + 1;
END;

Zaleznie od potrzeb z pomoca przychodza indexy

Ok,dziękuję!
Zatem po kolei:

1. Struktura danych startowych jest mniej więcej jak poniżej.
   Czy jest w nich cokolwiek co może sprawić, że STUFF/ FOR XML PATH działą u mnie tak maskarycznie wolno?

2. Indeksy - może to dla mnie jakieś światełko w tunelu:) W takiej sytuacji indeks powinien być założony tylko na kolumnie Ticket?

3. A może znaczenie ma, że działam na wcześniej stworzonym widoku?

Ticket Code Day
6233 10.99.40 1/25/2018
6233 19.M9.M9 1/15/2018
6233 19.M9.M9 1/15/2018
6233 19.A9.MM 1/15/2018
6233 19.MM.MM 1/12/2018
6233 19.MM.MM 1/10/2018
6233 19.M9.M9 1/9/2018
6233 19.M9.M9 1/9/2018
6233 19.M9.M9 1/9/2018
6233 19.M9.M9 1/9/2018
6233 19.M9.M9 1/9/2018
6245 19.B8.M4 1/26/2018
6245 19.B8.M4 1/26/2018
6245 19.B8.M4 1/25/2018

Dziękuję wszystkim za pomoc. Finalnie założyłem indeks na obu kolumnach i wynik przeszedł moje najśmielsze oczekiwania - 80 tys rekordow zostało przemielonych w 2 sekundy:)