[Patres]

#java #mongodb #nosql #programowanie
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?

[Saly]

1 kolekcja:

2 kolekcje:

@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 z tranzakcyjnością

Tutaj zachowanie relacyjności jest ok, bo ChatThread zmienia się dużo rzadziej niż ChatMessageEntry powstaje a ChatMessageEntry jest niemutowalne

[twojStaryJebqnany]

Mongos przyjmuje, ze dokumenty powinny byc w miarę małe (do 16mb) więc nie powinieneś pchać zbyt dużo do jednego dokumentu.

[Patres]

@Saly 9 @twojStaryJebqnany dzięki, tak też myślałem

[nad__czlowiek]

@Patres: gdzie masz encje jak tutaj są dokumenty? Mieszasz pojęcia SQL z noSQL. To dużo zależy od powiązania i od tego czy będziesz dużo zapisywał/odczytywał

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 do postu
Update komentarza do