Aktywne Wpisy
dontwolf +537
Część druga bitwy. 4 minuty znamienitej zabawy. Rumińskie pięści vs miętki rogal.
Byłoby szybciej jakbym zrobił szybciej. Cześć trzecia będzie może za pół roku
#heheszki #rumun #crossmemizm #blender
Byłoby szybciej jakbym zrobił szybciej. Cześć trzecia będzie może za pół roku
#heheszki #rumun #crossmemizm #blender
rales +179
tag do obserwowania --> #sredniasondazysejm
CZERWIEC 2024
1. Koalicja Obywatelska - 32,4% - 169 mandaty (⬆ 1,9%)
2. Prawo i Sprawiedliwość - 31,1% - 181 mandaty (⬆ 0,2%)
CZERWIEC 2024
1. Koalicja Obywatelska - 32,4% - 169 mandaty (⬆ 1,9%)
2. Prawo i Sprawiedliwość - 31,1% - 181 mandaty (⬆ 0,2%)
Stoimy z chłopakami przed pewnym dylematem i brakuje nam wiedzy aby być w stanie go jakoś rozstrzygnąć. Obecnie sprawa wygląda tak, że jest sobie baza MSSQL która ma od pyty procedur składowanych w których to dzieje się cała magia. Danych jest bardzo dużo i przychodzą non stop, backend jest szczątkowy - właściwie tylko przewala gotowce z bazy do frontu. Mówimy o potencjalnie setkach gigabajtów danych, które to mogą być niekiedy pobierane w ilości wielu gb na raz celem zrobienia np. agregacji do wykresów. Obecnie robi to baza w wewnętrznej procce i backend dostaje tylko mały zagregowany już odpowiednio pakiet danych, więc działa to jako tako.
No ale procedury składowane śmierdzą, bo uwiązują jajca do konkretnego silnika baz danych a w dzisiejszych czasach można się zastanawiać czy baza na pewno szybciej przeliczy. NoSQL nie ma procek składowanych, jest dosyć szybkie i masz podejście "code-first" w gratisie bez żadnych dziwnych tańców, aczkolwiek sam model danych to jeden wielki burdel i w pewnym momencie jak to spuchnie, to może się zrobić chaos nad którym normalnie panowałyby relacje.
Macie jakieś doświadczenia z tym związane aby mieć porównanie?
Co byś wybrał?
Komentarz usunięty przez autora
JOIN
nie jest relacją, tylko operacją w algebrze relacji. Tutaj dane wewnątrz tabeli są w "relacji", bo są ze sobą silnie związane (wewnątrz wierszy i kolumn). "Relacje" jakoJOIN
y istnieją tylko na wysokim poziomie dla "człowieka". Więc to jest problem z tłumaczeniem algebry a nie nomenklaturą, boJOIN
nie oznacza ani "relacji" ani "związku".JOIN
y to nie relacje, tylko operacje na relacjach, niczym dodawanie przy liczbach.Często nie ma tylu danych, te milisekundy opóźnienia na jednej operacji nie mają znaczenia, za to czas programisty jest drogi.
JOIN
y w nierelacyjnych DB (np. w CouchBase mamyJOIN
y).Zastanów się jak dobrze u was z optymalizacją takich rzeczy w kodzie. Jeżeli np, często zdarza się że wewnątrz jednej pętli kusi was żeby napisać drugą pętlę (czytaj - użyć LINQ), to raczej zostań przy bazie, chyba że dokładnie wiesz co jaki będzie miało koszt obliczeniowy.
Jeżeli tak jak piszesz, jedna kwerenda będą tysiące lub miliony rekordów - głosowałbym za bazą.
Pisanie agregacji w kodzie bywa ciężkie. Baza ma już indeksy, których może użyć, Ty w kodzie nie masz, musisz je zrobić żeby ich użyć, co może chwilę trwać. Możliwe nawet że będziesz musiał stworzyć kilka własnych dziwnych rozwiązań, żeby to jakoś działało.
Jeśli chodzi o backend, zamierzasz używać jakiegoś ORM-a? Zakładam że tak, to też może mieć duże znaczenie. Odpowiednio zoptymalizowany ORM będzie działał naprawdę dobrze, ale dobre zoptymalizowanie ORM (nawet pod konkretne kwerendy) może zająć duuużo czasu i trzeba się tym zająć od samego
@jaggi: Co najwyżej Dappera.