[MySQL] zapytanie laczace 2 kolumny, zestawic wartosci kol. B dla unikatowych wartosci kol. A Opcje

[Rynraf]

Mam kolumny 'kol1' i 'kol2'.

Maja przykladowa zawartosc

Kod

---------------
| kol1 | kol2 |
---------------
|  A   |  x   |
|  A   |  e   |
|  A   |  d   |
|  B   |  t   |
|  B   |  m   |
|  B   |  p   |
|  B   |  k   |
|  B   |  t   |
---------------

Jak zrobic, jakie zapytane napisac, aby tak zmodyfikowac ta tabele,
np. tworzac z niej nowa, gdzie z 'kol1' otrzymane zostana rekordy unikatowe,
a w 'kolX' zostana wpisane wartosci rekordow z 'kol2' przyporzadkowane
do danej wartosci z 'kol1'.

Wynik oczekiwany:

Kod

-------------------------
| kol1 |       kolX     |
-------------------------
|  A   |  x; e; d       |
|  B   |  t; m; p; k; t |
-------------------------

Pytanie - jak tego dokonac?
Wynikiem ma być nowa tabela z danymi, albo zmodyfikowanie względnie istniejącej tabeli.

[kitol]

[SQL] pobierz, plaintext 
SELECT kol1,GROUP_CONCAT(kol2) AS kolX FROM tabela GROUP BY kol1
[SQL] pobierz, plaintext 

Nową tabelę utworzysz dodając na początku tego zapytania "CREATE TABLE nazwa_tabeli "

[JoShiMa]

Tylko nowa tabela będzie bez sensu IMO

[kitol]

W jakim sensie "bez sensu"? Rynraf napisał przecież że chce utworzyć nową tabelę, a zapytanie:

[SQL] pobierz, plaintext 
CREATE TABLE nazwa_tabeli
SELECT kol1,GROUP_CONCAT(kol2) AS kolX FROM tabela GROUP BY kol1
[SQL] pobierz, plaintext 

utworzy nową tabelę.

Modyfikacja źródłowej tabeli za pomocą UPDATE nie wchodzi w grę bo tabela końcowa ma mniejszą liczbę wierszy (otrzymamy powtarzające się wiersze)

[JoShiMa]

W jakim sensie "bez sensu"? Rynraf napisał przecież że chce utworzyć nową tabelę, a zapytanie:

[SQL] pobierz, plaintext 
CREATE TABLE nazwa_tabeli
SELECT kol1,GROUP_CONCAT(kol2) AS kolX FROM tabela GROUP BY kol1
[SQL] pobierz, plaintext 

utworzy nową tabelę.

To się zgadza, ale format nowej tabeli jest bez sensu. Niewygodny.

[kitol]

Po części się zgodzę. Trzymanie danych w formacie wartości oddzielonych separatorami w polu jest niewygodne, gdyż komplikuje operacje wykonywane na takim polu. Jednak czasami użycie funkcji GROUP_CONCAT jest bardzo przydatne do generowania raportów (tworzenia list wartości). Jako przykład mogę podać generowanie pliku CSV który ma zdefiniowaną strukturę, taką że w jednym polu jest np. lista zdjęć oddzielonych przecinkiem. Jeżeli wygenerowana tabela ma być wykorzystana do trzymania danych to się z tobą zgodzę, utrudni to późniejszą pracę z danymi. Rynraf nie przedstawił nam dlaczego potrzebuje takiego formatu danych. Równie dobrze może chcieć stworzyć tabelę tymczasową do generowania jakiegoś pliku.

[JoShiMa]

Po części się zgodzę. Trzymanie danych w formacie wartości oddzielonych separatorami w polu jest niewygodne, gdyż komplikuje operacje wykonywane na takim polu. Jednak czasami użycie funkcji GROUP_CONCAT jest bardzo przydatne do generowania raportów (tworzenia list wartości).

Zgadza się, ale to się robi dynamicznie a nie przez tworzenie dodatkowej tabeli. Teraz efekt jest taki. Masz dodatkową tabelę w beznadziejnym formacje. Musisz robić zapytania aktualizujące tę tabelę i dodatkowo zapytania czytające dane z niej wtedy kiedy Ci potrzeba. Jaki to ma sens?

[Rynraf]

Dziękuję pięknie.

Porgupowałem to sobie w ten właśnie sposób:

[SQL] pobierz, plaintext 
SELECT kluczowakolumna,kolumna1,GROUP_CONCAT(grupowanakolumna SEPARATOR '; ') AS pogrupowane, kolumnN, kolumnaK FROM tabela GROUP BY kluczowakolumna
[SQL] pobierz, plaintext 

Automatyczne wrzucenie tego do drugiej tabeli nie wychodziło sam nie wiem czemu, więc uzyskany wynik wyeksportowałem.

Tak jak napisał kitol to nie ma być wynik do dalszego trzymania w bazie, przeszukiwania itp. a jedynie do stowrzenia czegoś w rodzaju raportu, pliku właśnie.

Nie znałem właśnie funkcji GROUP_CONCAT(kolumna).

[kitol]

JoShiMa: Nie wynika to z mojego zapytania (brak TEMPORARY), ale jak napisałem 2 posty niżej miałem na myśli tabelę tymczasową. Nie taką, która siedzi cały czas w bazie, ale tworzaoną przez np. skrypt. W przypadku gdybym chciał mieć taką tabelę na stałe raczej utworzyłbym widok - odpada zabawa z aktualizacją danych a i pytanie czytające jest prostsze.

Rynraf: jeżeli generujesz plik tekstowy to radzę zrobić to za pomocą SELECT .... INTO OUTFILE 'plik.csv' - odpada zabawa z przetwarzaniem rezultatu zapytania przez PHP i zapisywanie do pliku.

[JoShiMa]

JoShiMa: Nie wynika to z mojego zapytania (brak TEMPORARY), ale jak napisałem 2 posty niżej miałem na myśli tabelę tymczasową. Nie taką, która siedzi cały czas w bazie, ale tworzaoną przez np. skrypt.

No OK, ale jaki jest sens tworzenia takiej tabelki? Pytam bo nie jestem twardogłowa i usiłuję zrozumieć.

[kitol]

No cóż. Powody stosowania tabel tymczasowych podam dwa:
1) Nieumiejętnosć projektowania bardziej złożonych zapytań. Zdarzało mi się widzieć całe skrypty SQL-owe które można by zrealizować jednym zapytaniem. Niewielu programistów rodzi się z umiejętnością zapisania wszystkiego w jednym zapytaniu. Lepiej wykonać kilka zapytań z tabelami tymczasowymi niż wiele SELECT-ów i przetwarzać później dane w PHP.
2) Stara wersja bazy danych która nie potrafi wykonać złożonych zapytań.

[JoShiMa]

Lepiej wykonać kilka zapytań z tabelami tymczasowymi niż wiele SELECT-ów i przetwarzać później dane w PHP.

Lepiej lepiej, ale sam powiedz, że najlepiej by było umieć te bardziej skomplikowane zapytania, prawda?

[kitol]

Oczywiście, że lepiej, ale nikt się z tym nie rodzi. Znajomości SQL-a nie można się nauczyć w jeden dzień. Zakładania tabel tymczasowych nie uważam za coś złego o ile się na tym nie poprzestaje. Nie jest to profesjonalne, ale może być krokiem do osiągnięcia profesjonalizmu.

BTW. Przyszła mi do głowy jeszcze jedna myśl. MySQL pozwala na tworzenie tabel HEAP (memory). Teoretycznie często pobierane dane można by wrzucić do takiej tabeli. Mogło by to przyspieszyć ich pobieranie. Dane w takiej tabeli powinny być w formacie takim jakiego potrzebujemy w PHP (czyli na przykład łączone przez GROUP_CONCAT).W takim przypadku taki format danych byłby chyba dopuszczalny (tylko do odczytu jednym SELECTEM)

[szopen]

chyba nikt nie wspomniał o widoku