[grajlord]

Jak poprawnie tworzyć reprezentację obiektów w bazie danych i definiować ich metody?
Mam opcję 1) odpytywać bazę wielokrotnie z użyciem jasno zdefiniowanych metod 2) odpytywać bazę 1 raz, a następnie informacje wyciągać za pomocą jakichś funkcji ad hoc.

Rozwiązanie 1) jest bardziej przejrzyste, bardziej "modularne", można te metody wykorzystywać ponownie w innych sytuacjach, korzystać z nich bezpośrednio itd.; z kolei rozwiązanie 2) generuje mniej zapytań do bazy.
Prosty przykład: def czy_wiezie_bulki_wedliny(self, baza_danych) która sprawdzi, czy obiekt klasy Tir wiezie nam bułki, wędliny.

Definicja metody dla opcji 1:

def czy_wiezie_bulki_wedliny(self, baza_danych):
  ma_bulki = self.czy_wiezie_bulki(baza_danych)
  ma_wedliny = self.czy_wiezie_wedliny(baza_danych)
  return ma_bulki and ma_wedliny

Definicja dla opcji 2:

def czy_wiezie_bulki_wedliny(self, baza_danych):
  przedmioty = self.co_wiezie(baza_danych)
  # czy_ma_co_trzeba = jakas_zewnetrzna_funkcja(przedmioty) # albo:
  czy_ma_co_trzeba = [przedmiot in ['bulka', 'wedlina'] for przedmiot in przedmioty]
  return any(czy_ma_co_trzeba)

#python

[Budek24]

@grajlord: Proponuje wykonać jedno zapytanie w przypadku baz SQL, a w przypadku NoSQL to najlepiej do tego stworzyć indeks ;)

[grajlord]

@Budek24: Ale jest to przyjęta praktyka, że robi się jedno zapytanie, czy zależy od kontekstu/zastosowania/ilości zapytań?

[filozof900]

@grajlord: praktyka jest taka, zeby pobierac tylko te dane ktore sa potrzebne, jak najszybciej sie da, jak najmniej obciążając baze danych (czyli zwykle jak najmniej zapytan)

[Budek24]

@grajlord: Generalnie silniki baz danych sobie świetnie radzą z wybieraniem odpowiednich danych. Oczywiście trzeba umiejętnie z nich korzystać.

[pitersi]

@filozof900 @Budek24 A jeżeli mamy taką sytuację że interesuje nas jak wędlina dotarła do sklepu. Jest x% szansy że jednym tirem 1-x% szans że była przeładowana i później znów rekurencja. Załóżmy że liczba tirów jest skończona i wynosi y. Jak byście pytali bazę? O wszystkie tiry, czy o pierwszy i o kolejne tylko w przypadku przeładunku?
Czy też zdobić obydwa rozwiązania przetestować i zastosować wydajniejsze?

[pitersi]

Ok mam odpowiedź. Przenieść logikę rekurencji do bazy SQL tak aby było jedno zapytanie które będzie zwracać odpowiednią liczbę wierszy - zawsze tyle ile oczekujemy.

[filozof900]

@pitersi w przypadku szynki to wszystkie naraz ( ͡º ͜ʖ͡º)

[filozof900]

@pitersi o to to, tak prezentować dane żeby było można je wydajnie i łatwo wczytywać

[pitersi]

@filozof900 ok ale załóżmy że nie masz wpływu na kształt bazy danych i możesz tylko odczytywać. Czy np coś takiego byś zrobił: https://ask.sqlservercentral.com/questions/141365/recursive-cte-over-partitionsdetail-in-code.html Czy też byś pytał o wszystko i logikę przeniósł do np python. Jeżeli byś zostawił w SQL to czy Twoja decyzja by się zmieniła jeżeli byś musiał za chwilę podobną operację znów wykonać na tym samym zakresie danych?

[pitersi]

@filozof900 bo ja bym to sformułował tak: Minimalizować liczbę zapytań oraz przesyłanych danych chyba że nie sami ( lub nie jeden nasz wątek) korzystamy z bazy i nasze select wymagają przetworzenia tych samych rekordów bazy danych wielokrotnie pod różnym kontem to wtedy warto się zastanowić nad przesłaniem ich do aplikacji w większym niż minimalnym zakresie.
No chyba że mamy jakiś wywalony w kosmos serwer i nasze zapytania nie spowolnią zapytań innych ludzi

[filozof900]

@pitersi w tym wypadku wolałbym cte ale wiesz... Zależy ;) jeżeli 99% produktów jeździ jednym tirem a reszta dwoma trzema to być może nie musisz się przejmowac i pytać po 2-3 razy

[piotrb]

@grajlord: Jak zwykle odpowiedź brzmi: to zależy. Jeżeli masz już obiekt pobrany z bazy danych, to działasz na jego atrybutach (i to jest podejście prawidłowe w większości zastosowań - oszczędzasz czas programisty). Jeżeli nie, to możesz na dwa sposoby: przez ORM lub przez bezpośrednie zapytania (i to jest podejście prawidłowe tylko w sytuacji walki z wąskim gardłem) i wtedy pytasz o obydwa pola w select.

[piotrb]

@grajlord: Jeszcze jedna rzecz mi się przypomniała: ze względu na wydajność współpracy z bazą danych krytyczne i problematyczne są wyszukiwania danych i ew. wstawianie danych. Odczyt pojedynczego obiektu z bazy (chyba, że byłby ogromny) po id jest prosty i szybki.

[grajlord]

@Budek24: @pitersi: @filozof900: dzięki za pomoc i dyskusję ( ͡° ͜ʖ ͡°)
@piotrb: Dzięki. Czyli w skrócie próbuję znaleźć jakieś optimum pomiędzy prostotą kodu, a ilością zapytań, ale z reguły dobrą praktyką jest pobieranie całego obiektu i operowanie na nim.

[piotrb]

próbuję znaleźć jakieś optimum pomiędzy prostotą kodu, a ilością zapytań

@grajlord: O, właśnie to, ale zawsze zaczyna się od prostoty kodu (i jest to ogólna zasada).