![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 1 495 Pomógł: 245 Dołączył: 1.07.2009 Skąd: Bydgoszcz Ostrzeżenie: (0%) ![]() ![]() |
Mam 2 tabele w bazie:
Wiadomosci: id_w od_kogo do_kogo tekst Userzy: id_u nazwa Kiedy user wysyła wiadomość (np. user o nazwie AAA i id=1 do usera BBB o id=2) to w tabeli wiadomości zostanie dodany rekord o wartości pól: od_kogo=1 i do_kogo=2:
Moje pytanie brzmi jak wyświetlić te wiadomości tak aby zamiast id userów pojawiły się ich nazwy. Normalnie nie miałem z tym problemów bo robiłem to tak: Ale tutaj jest problem bo przecież pola od_kogo i do_kogo oba są wartościami id z tabeli userzy. Jak skonsrtuować zapytanie aby SQL nie zgłupiał? |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D ![]() |
To może jako ciekawostkę dodam, że w systemach DB2 by przyspieszyć wykonywanie zapytań, niejawnie SELECTy w podzapytaniach są konwertowane do JOINa odpowiedniego. Jeśli coś takiego robi IBM to jak myślisz, czy inni twórcy silników bazodanowych nie robią podobnie by osiągnąć lepszą wydajność? Może się więc okazać, że choć nasze zapytania są od strony usera różne, to po stronie bazy mogą być albo niemal identyczne, albo identyczne wręcz i nasza debata jest tak naprawdę mało istotna. Oczywiście na pewno dzieje się to w określonych przypadkach, a nie zawsze. Ale daje to ciekawą podstawę pod dalszą dyskusję na temat sensowności optymalizacji (IMG:style_emoticons/default/winksmiley.jpg) Lepiej pisać jawnie JOIN, czy zdać się na silnik i konwersję niejawną między subquery a JOIN. O tej ciekawostce przeczytałem w necie i byla ona ponić efektem korespondencji z inżynierem IBM, gdy zapytano go o wydajność pomiędzy subquery i join w DB2 i powiedzial on tam o znikomej różnicy, ze względu właśnie na niejawna konwersję zapytania.
Od momentu rejestracji w tematach widziałem bowiem wiele nieoptymalizowanych zapytań, gdzie ludzie używali ewidentnie niewłaściwych, stworzonych zapewne na podstawie tutoriali netowych bez zrozumienia ich sensu. Sam nieraz bylem zmuszony używać subqueries, bo nie zawsze jest możliwe zastosowanie join, choćby w sytuacjach gdy musimy użyć odpowiedniego WHERE pole IN. Jeśli jednak silniki bazodanowe w dużej mierze mają zaimplementowaną konwersję podzapytań do join, to może się okazać, że w większości przypadków spór "subqueries vs join" jest podobny do wyższości wielkiej nocy nad bożym narodzeniem (IMG:style_emoticons/default/biggrin.gif) A narzut mały i niemal brak różnic jest związany właśnie z niejawną konwersją :] Może jednak to się wydzieli jako osobny wątek w optymalizacji? (IMG:style_emoticons/default/snitch.gif) Ten post edytował thek 23.08.2009, 17:11:36 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 19:34 |