Witam ponownie,

Powoli zbliżam się do końca prac, ale znów mam wydaje się banalny problem, ale na który nie potrafię znaleźć rozwiązania.

Mam tabele w bazie "rosters", w której takie dane:

[SQL] pobierz, plaintext 
id	player_id	position_id	team_id	club_id	league_id
363	24	6	2	6	NULL
367	28	6	2	20	NULL
368	26	7	2	6	NULL
359	27	5	2	20	NULL
358	33	5	2	6	NULL
353	31	7	45	5	NULL
352	25	6	45	5	NULL
 
[SQL] pobierz, plaintext 

i dane z tej tabeli chcę sobie raz na jakiś czas przenosić do tabeli "teams_history", która wyglada tak:

[SQL] pobierz, plaintext 
id	team_id	round_id	player_1	player_2	player_3	player_4	player_5	player_6
[SQL] pobierz, plaintext 

Chcę pobrać z "rosters" team_id i wpisac do "teams_history " do player_1 , player_2 ....itd zawodników, których ma w tabeli rosters ów team_id. (nie wiem czy nie zamieszałem).
Proszę o pomysł jak to rozwiązać.

Może ten artykuł Cię natchnie

Wygląda na to że źle sobie zaprojektowałeś bazę. Dwa błędy jakie widzę to to, że w tabeli historycznej trzymasz stałą liczbę zawodników. Zawsze wynosi 6? Po drugie po co przenosić te same dane do innej tabeli? Nie lepiej utworzyć jakiś widok który będzie korzystał z pierwszej tabeli?

tak, zawsze jest 6 zawodnikow.
A po co? "rosters" to aktualny sklad, na bieżącą kolejką. Teams_history to historia tych "rosterow". Chcę miec mozliwosc wrocenia do danych z poprzednich kolejek.



Wyższa szkoła jazdy jak dla mnie, "przedszkolaka"

W takim razie nie potrzebujesz dodatkowej tabeli a jedynie widoku z odpowiednio napisanym zapytaniem. Możesz to również zrobić osobną tabelą, ale jak sam napisałeś to "wyższa szkoła jazdy". Sprawdź co to Widok w SQL i zastanów się czy to na pewno nie to czego szukasz

"Widoki nie przechowują kopii zapisanych w tabelach danych." A mnie właśnie potrzeba jest kopia.

A czy nie da się tak, zeby przypisane do team_id w tabeli dane "player_id" (6) przypisac do szesciu roznych zmiennych?

Piękne zdanie... Trzeba się porządnie zastanowić co autor miał na myśli

Nadal będę się upierał że widok w tym przypadku jest lepszy. I wcale nie potrzebujesz tego archiwizować w osobnej tabeli. Nie będziesz chyba usuwał rekordów z tabeli po archiwizacji? Bo po co? Plusy widoku są takie że czego byś nie robił UPDATE, DELETE, INSERT od razu wpływa na zawartość widoku. W przypadku tabeli archiwizującej potrzebujesz triggery które będą nad tym wszystkim czuwać.

Może opiszę od strony usera. User ustawia sobie sklad na mecz. Zaczyna się kolejka, ma zablokowane transfery - nie moze kupowac/sprzedawac zawodnikow. Zawodnicy ktorych ma są właśnie w tabeli "rosters".
Podczas trwania kolejki user otrzymuje punkty.
I teraz ważne. Przed ponownym umożliwieniem transferów chcę zapisać gdzies sobie sklad jaki miał w kolejce, poniewaz po ponownym uruchomieniu transferow, user moze wymieniac zawodnikow, a ja nie bede mial mozliwosc sprawdzenia jaki sklad mial w poprzedniej kolejce. Stad pomysl o tabeli teams_history.

Co ważne, przy transferach zmieniają się własnie dane w tabeli "rosters"

Ale co chcesz zmieniać? Daj kolejną kolumnę ID_KOLEJKI.

USER 1


Widzisz że USER 1 w trakcie rozgrywki 100 po 10 kolejce zmienił drużynę na 2

O tym myslalem i skoro nie da sie inaczej chyba do tego bede musial wrocic.
A wyobrazalem sobie ze da się tak:
Pobieram dane team_id i tych sześciu player_id przypiszę do sześciu róznych zmiennych... Naprawdę nie da się tak?

Da się. Ale właściwie musisz napisać to samo zapytanie które będziesz miał w widoku.

A zdradzisz jak? czy odeslesz mnie do googla?

Musisz wyniki złączyć joinem. Mniej więcej:

[SQL] pobierz, plaintext 
SELECT team_id, round_id, player1.suma_punktow AS player1, player2.suma_punktow AS player2 ....
FROM rosters
LEFT JOIN ( zaptanie sumujace punkty zawodnika ) player1 ON ...
LEFT JOIN ( zaptanie sumujace punkty zawodnika ) player2 ON ...
[SQL] pobierz, plaintext 

analogicznie dla reszty zawodników.

Dziękuję z góry. Sprawdzę za kilka chwil.