Witajcie
Chciałbym zasięgnąć rady, otóż czy opłaca się przechowywać w bazie TimeSpan, który jest sumą kilkunastu timespan`ów.(również zawartych w bazie). Czy opłaca się to przechowywać w bazie czy lepiej przeliczyć to za każdym pobraniem?
Jeśli tak to jak przy użyciu automappera przekonwertować wszystkie sumy TimeSpan na wartości Tickets tak by baza nie wypluła błędu o przekroczeniu granic TimeSpan?
0
0
Wybacz, nie jest to zbyt zrozumiałe.
Opłaca tzn ???
Mówimy o "opłaca się" w pionie, w poziomie .. czy w relacji ?
0
@AnyKtokolwiek: ogólnie, pod względem wydajności, jaka jest ogólna zasada w takiej sytuacji, sumy można sobie wyliczyć za każdym razem na podstawie pojedynczych dni-timespan. Czy warto to w ogóle przechowywać w bazie
0
Jak to przechowujesz? Najlepiej byłoby jakbyś wrzucil schemat
0
A jak często się zmienia ten timestamp? Jeśli raz to ja bym chyba zostawił w bazie.jesli obliczany jest często to nie bo szkoda zapisywać.
1
Ale na to nie ma dobrej odpowiedzi, za dostęp do tej informacji będziesz musiał zapłacić albo pamięciowo albo wydajnościowo. Sam musisz zdecydować jak za to chcesz zapłacić.
Pozdrawiam,
mr-owl
1
Jeśli to pole miałoby być użyte w którymś z warunków w zapytaniu (where/join...on/group by), to warto przeanalizować plany zapytań i na ich podstawie podjąć decyzję o faktycznym jego dodaniu. Jeśli to pole nie byłoby używane do filtrowania rekordów, to moim zdaniem nie ma sensu go dodawać, ewentualnie można dodać je w view, acz decyzja zależy od tego, jak to pole byłoby używane.
0
Samemu musisz sprawdzić czy daje to jakiś przyrost wydajności. Ciężko powiedzieć nie wiedząc ile masz tych danych i jak często musisz te timestampy sumować. Zależy też jaki silnik bazy - jeśli często używasz tej sumy to warto choćby dodać w bazie (na przykładzie MSSQL/Oracle) computed column - wtedy kolumna nie zajmuje dodatkowego miejsca, ale pozwala na uproszczenie selectów. Wystarczy dodać słówko "PERSISTED" (lub automatic w oracle) i kolumna będzie fizycznie zrzucana na dysk - możesz łatwo porównać performance obu zapytań. W większości przypadków powiedziałbym że "persisted" się "nie opłaca", za to trzymanie osobnego computed column może być przydatne i nic nie kosztuje.
https://docs.microsoft.com/en-us/sql/relational-databases/tables/specify-computed-columns-in-a-table?view=sql-server-ver15
https://www.oracle.com/technetwork/database/database-technologies/rdb/automatic-columns-132042.pdf