Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [MySQL] zapytanie laczace 2 kolumny
Forum PHP.pl > Forum > Bazy danych > MySQL
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
  1. SELECT kol1,GROUP_CONCAT(kol2) AS kolX FROM tabela GROUP BY kol1


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:
  1. CREATE TABLE nazwa_tabeli
  2. SELECT kol1,GROUP_CONCAT(kol2) AS kolX FROM tabela GROUP BY kol1

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
Cytat(kitol @ 18.09.2008, 20:25:46 ) *
W jakim sensie "bez sensu"? Rynraf napisał przecież że chce utworzyć nową tabelę, a zapytanie:
  1. CREATE TABLE nazwa_tabeli
  2. SELECT kol1,GROUP_CONCAT(kol2) AS kolX FROM tabela GROUP BY kol1

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
Cytat(kitol @ 23.09.2008, 14:13:20 ) *
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:
  1. SELECT kluczowakolumna,kolumna1,GROUP_CONCAT(grupowanakolumna SEPARATOR '; ') AS pogrupowane, kolumnN, kolumnaK FROM tabela GROUP BY kluczowakolumna


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
Cytat(kitol @ 23.09.2008, 19:40:36 ) *
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
Cytat(kitol @ 25.09.2008, 20:56:10 ) *
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
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.