Aktywne Wpisy

MetalowyBieg +307
Zatrudnili u mnie takiego skąpego boomera i naprawdę ciężko się na to patrzy.
Człowiek liczy każdy grosz jakby żył w permanentnym kryzysie. Rano przychodzi z kanapkami z domu, herbata w termosie bo przecież szkoda wydać parę złotych na coś na miejscu. Energetyk? Nie ma mowy. Wszystko „bo taniej w domu”.
W ciągu dnia zero wydatków. Kompletnie. Jakby wydanie jakichkolwiek pieniędzy było problemem. My czasem coś zamówimy albo wyskoczymy po jedzenie, a on siedzi z
Człowiek liczy każdy grosz jakby żył w permanentnym kryzysie. Rano przychodzi z kanapkami z domu, herbata w termosie bo przecież szkoda wydać parę złotych na coś na miejscu. Energetyk? Nie ma mowy. Wszystko „bo taniej w domu”.
W ciągu dnia zero wydatków. Kompletnie. Jakby wydanie jakichkolwiek pieniędzy było problemem. My czasem coś zamówimy albo wyskoczymy po jedzenie, a on siedzi z

moll +88
źródło: 1000020022
Pobierz



Mirki, pierwszy raz pracuję z bazą noSql i zastanawiam się jak powinny wyglądać encje. Skoro bazy te nie są nastawione na relacje to jeżeli mam wątki czatu i wiadomości czatu to czy wątki czatu powinny przechowywać listę wiadomości (1 kolekcja), czy może mieć 2 kolekcje: wątki czatu i wiadomość czatu z id wątków. W relacyjnej bazie danych sprawa jest prosta - 2 tabelki.
1 kolekcja:
@Document
public record ChatThread(
@Id
String id,
String name,
LocalDateTime createdAt,
LocalDateTime modifiedAt
)
@Document
public record ChatMessageEntry(
@Id
String id,
@Indexed
String chatThreadId,
String content,
ChatMessageSender seder,
@Indexed
LocalDateTime createdAt
)
vs
2 kolekcje:
@Document
public record ChatThread(
@Id
String id,
String name,
LocalDateTime createdAt,
LocalDateTime modifiedAt,
List<ChatMessageEntry> messages
)
public record ChatMessageEntry(
String id,
String content,
ChatMessageSender seder,
LocalDateTime createdAt
)
Pewnie jak zwyle to zależy, ale w tym przypadku jakbyście to zrobili?
@Patres: masz na odwrót
Co do podziału to jestem za dwiema odzielnnymi kolekcjami, bo wyobraż sobie wątek na tysiące wiadomości. Updatowanie jednego obiektu w kolekcji jest wolne i generuje problemy związane
Logiczne w postach/komentarzach wydaje się, że komentarze są mocno zależnego od postu (tight coupled) więc opłaca się je trzymać razem, zazwyczaj nie wykonuje się jakichś skomplikowanych operacjach na komentarzach - od typowy CRUD,
Get jeden post + wiele komentarzy
Create komentarza