@smalczyk1: teoretycznie nie powinno się logiki robić na bazie, ale jeżeli ma to Ci uratować produkcję, to czasami warto przenieść jakieś większe obliczenia na bazę. Jednak trzeba pamiętać, że nie zawsze przeniesienie obliczeń na bazę przyśpieszy działanie. Baza zazwyczaj jest najsłabszym ogniwem i przy większym ruchu/ilości danych Twoje wyliczenia mogą ją... no wiesz ( ͡º͜ʖ͡º)
@smalczyk1: Nie wiem o jakiej platformie mówisz ale powiem jakie mam wnioski na Android + SQLite. Jeśli obliczenia opierają się na większej liczbie rekordów to lepiej napisać dobre zapytanie SQL, bo do obliczeń w programie i tak musisz najpierw dane zaciągnąć.
Czy wykonywanie jakiś skomplikowanych obliczeń powinno się robić w samym programie czy w funkcji sql?Co jest bardziej wydajne?
@smalczyk1: to zależy od architektury aplikacji, od wymagań wobec niej.
teoretycznie nie powinno się logiki robić na bazie,
@CppPolska: nie ma żadnych przeszkód formalnych przed logiką na bazie. Aktualnie się od takich rozwiązań odchodzi, taka moda jest, żeby wszystko było bezstanowe i korzystało z baz nierelacyjnych, ale podejrzewam, że to bardziej ucieczka
@wykopyrek: powodzenia w kontrolowaniu i debugowaniu apki z logiką na bazie (｡◕‿‿◕｡) Ja już takie zabawy mam za sobą, nie ma to jak pliki źródłowe ʕ•ᴥ•ʔ
powodzenia w kontrolowaniu i debugowaniu apki z logiką na bazie (｡◕‿‿◕｡)
@CppPolska: nie święci garnki lepią¯\_(ツ)_/¯ Niby architektura monolitu jest zła na tyle różnych sposobów, ale jak się próbuje silnik zabić zapytaniami, to jak nie przyłoży, wąskie gardło zawsze na I/O. Ale to trzeba mieć solidnego klienta, bo licencja kosztuje raz, specjaliści tylko od tej technologii kosztują dwa.
Nie, jak zrobi się to dobrze. Jak nie monolit, to serwisy. Ale i jedno i drugie ma swoje wykorzystanie, swoje wady i zalety. Takie decyzje powinna podejmować osoba, która już sporo systemów widziała i zna ich wady/zalety właśnie.
@smalczyk1: zależnie od przypadku warto wykorzystać bazę do pewnych typów obliczeń np proste agregacje na dużych ilościach rekordów. Wyniki wtedy zasilają liczarkę po stronie aplikacji w "prefabrykaty" na których są realizowane bardziej skomplikowane operacje. Rozwiązanie win-win gdy pasuje do problemu, bo querki są proste i wydajne a complexity jest w aplikacji gdzie łatwiej jest się z nim obchodzić
@smalczyk1: zalezy. Czasem oplaca sie po stronie programu, czasem po stronie serwera. Jesli potrzeba do obliczen duzo danych z serwera, to bedzie oplacilo robic sie to po stronie serwera, jesli natomiast ilosc danych jest niewielka, a obliczenia skomplikowane, lepiej moze wypasc to na koncowce.
#programowanie
Komentarz usunięty przez autora
@smalczyk1: Nie wiem o jakiej platformie mówisz ale powiem jakie mam wnioski na Android + SQLite. Jeśli obliczenia opierają się na większej liczbie rekordów to lepiej napisać dobre zapytanie SQL, bo do obliczeń w programie i tak musisz najpierw dane zaciągnąć.
@smalczyk1: to zależy od architektury aplikacji, od wymagań wobec niej.
@CppPolska: nie ma żadnych przeszkód formalnych przed logiką na bazie. Aktualnie się od takich rozwiązań odchodzi, taka moda jest, żeby wszystko było bezstanowe i korzystało z baz nierelacyjnych, ale podejrzewam, że to bardziej ucieczka
@CppPolska: nie święci garnki lepią¯\_(ツ)_/¯
Niby architektura monolitu jest zła na tyle różnych sposobów, ale jak się próbuje silnik zabić zapytaniami, to jak nie przyłoży, wąskie gardło zawsze na I/O.
Ale to trzeba mieć solidnego klienta, bo licencja kosztuje raz, specjaliści tylko od tej technologii kosztują dwa.
Nie, jak zrobi się to dobrze. Jak nie monolit, to serwisy. Ale i jedno i drugie ma swoje wykorzystanie, swoje wady i zalety. Takie decyzje powinna podejmować osoba, która już sporo systemów widziała i zna ich wady/zalety właśnie.