#programowanie #sql mam prostą relację jeden-do-wielu. W tabeli rodziców są jakieś tam dane - potrzebuję wszystkich. W tabeli dziecka mam jedną kolumnę z dużą ilością tekstu ale potrzebuję tylko 45 pierwszych znaków i nie potrzebuję żanych innych danych z tej tabeli. Tzn. chcę mieć na wyjściu rodzica z listą skróconych wartości ze wszystkich tabeli dzieci.
Mogę zrobić procedurę, że po otrzymaniu ID rodzica, query mi zwróci tabelkę z jedną kolumną varchar(45) i tyle ale mam wtedy dużo zapytań bo najpierw biorę wszystkich rodziców, a później dla każdego z nich pytam o tę procedurę... dlatego nie wiem czy to jest dobre rozwiązanie.
Z drugiej strony jak dam JOIN to dostanę wieeelką tabelę z danymi rodzica powtarzanymi np. 100 razy... oczywiście sobie tam w programie wywalę co niepotrzebne ale nie wiem co lepiej... A czy B? chyba, że jest jeszcze jakaś trzecia opcja... :P
@qtsms: Ogólnie, uniwersalnym rozwiązaniem są dwa zapytania zamiast joina. U mnie w pracy mamy temp table, do którego wstawiamy dane rodziców i potem wysyłamy do klienta najpierw wszystkie dane rodziców, a potem joina "id rodzica" z danymi dziecka, a klient robi joina na danych korzystając z sortowania kubełkowego. Sprawdza się przy przepustowości połączenia baza-klient rzędu 50kB/s (niska jakość rozwiązania oferowana przez Microsoft Azure).
@qtsms: zależy od problemu - co chcesz później z tym zrobić?
Jeżeli jakiś agregat i idziesz w stronę hurtowni danych, to opcja nr 1, hash-join'y, parallelism etc. Jeżeli chcesz z takimi danymi coś w międzyczasie zrobić, to pozostaje tylko opcja nr 2. Jeżeli ma to być system OLTP (zwykły, operacyjny), to opcja nr 1 i upewnienie się, że indeksy są wszędzie tam, gdzie trzeba.
CREATE TABLE #tempmeetings (idMeetings INT, name VARCHAR(45), date DATE); INSERT INTO #tempmeetings SELECT idMeetings, name, date FROM Meetings; SELECT * FROM #tempmeetings; SELECT * FROM Topics WHERE Meetings_id IN (SELECT idMeetings FROM #tempmeetings); Można zmienić tu kilka rzeczy, np. próbować użyć JOIN zamiast WHERE lub EXISTS zamiast IN, ale to już zależy od konkretnego przypadku.
Dla rozwiązania pierwszego dostanę Meetings.name i Meetings.date tyle razy ile jest rekordów w tabeli Topics, a nie tyle razy ile jest w tabeli Meetings czyli dużo razy... zakładając, że w tej tabeli nie będzie tylko tych dwóch kolumn, a dużo więcej i np. także stringi, a nie tylko ładne cyferki to otrzymam wielką paczkę danych gdy potrzebuję tylko małej częsci.
Z drugiej strony, osobne pytanie dla każdego rekordu Meetings spowolni cały proces
@Ginden: nie rozumiem twojego rozwiązania. (1) Tworzę tabelę tymczasową identyczną jak tabela Meetings, (2) wsadzam do niej dane z oryginalnej tabeli Meetings, (3) wybieram wszystko z tej tymczasowej tabeli ((A) dlaczego nie robię SELECT na oryginalnej tabeli i (B) co z tym robię?), a na koniec (4) wybieram wszystkie rekordy z tabeli Topics których klucze znajdują się w tej tymczasowej, identycznej z oryginalną tabeli... czyli wszystkie. Zupełnie nie czaję... chyba,
@qtsms: Pominąłem elementy dwa - do tabeli tymczasowej wkładasz tylko te wiersze, które chcesz. Jeśli nie robisz WHERE lub jest on nieskomplikowany to możesz zrobić bezpośrednio z tabeli.
Mogę zrobić procedurę, że po otrzymaniu ID rodzica, query mi zwróci tabelkę z jedną kolumną varchar(45) i tyle ale mam wtedy dużo zapytań bo najpierw biorę wszystkich rodziców, a później dla każdego z nich pytam o tę procedurę... dlatego nie wiem czy to jest dobre rozwiązanie.
Z drugiej strony jak dam JOIN to dostanę wieeelką tabelę z danymi rodzica powtarzanymi np. 100 razy... oczywiście sobie tam w programie wywalę co niepotrzebne ale nie wiem co lepiej... A czy B? chyba, że jest jeszcze jakaś trzecia opcja... :P
U mnie w pracy mamy
temp table, do którego wstawiamy dane rodziców i potem wysyłamy do klienta najpierw wszystkie dane rodziców, a potem joina "id rodzica" z danymi dziecka, a klient robi joina na danych korzystając z sortowania kubełkowego.Sprawdza się przy przepustowości połączenia baza-klient rzędu 50kB/s (niska jakość rozwiązania oferowana przez Microsoft Azure).
@Taczi: z distinct mam jedną listę, a potrzebuję osobnej listy dla każdego rekordu.
@Ginden
źródło: comment_GXnNvOY55awYvGiQoYTZt0howl6Hz71o.jpg
PobierzJeżeli jakiś agregat i idziesz w stronę hurtowni danych, to opcja nr 1, hash-join'y, parallelism etc.
Jeżeli chcesz z takimi danymi coś w międzyczasie zrobić, to pozostaje tylko opcja nr 2.
Jeżeli ma to być system OLTP (zwykły, operacyjny), to opcja nr 1 i upewnienie się, że indeksy są wszędzie tam, gdzie trzeba.
CREATE TABLE #tempmeetings (idMeetings INT, name VARCHAR(45), date DATE);INSERT INTO #tempmeetings SELECT idMeetings, name, date FROM Meetings;
SELECT * FROM #tempmeetings;
SELECT * FROM Topics WHERE Meetings_id IN (SELECT idMeetings FROM #tempmeetings);
Można zmienić tu kilka rzeczy, np. próbować użyć JOIN zamiast WHERE lub EXISTS zamiast IN, ale to już zależy od konkretnego przypadku.
Z drugiej strony, osobne pytanie dla każdego rekordu Meetings spowolni cały proces
Wszystkie joiny zawsze zwrócą Ci dużo danych.