Używanie surrogate key wraz z composite key

0

Ostatnio gdzieś przeczytałem, że do tabeli mającej composite key niebędącej jedynie jakąś pivot table w many-to-many, ale mającej też "własne" kolumny, powinno zawsze się dodawać surrogate key, który będzie kluczem głównym. Jedną z zalet takiego podejścia ma być możliwość zaprojektowania ładnych ścieżek w API. Tzn. zamiast robić DELETE /api/memberships?playerId=1&teamId=1 można zrobić ładne DELETE /api/memberships/1. Co o tym myślicie?

1

No jeśli to jakaś encja, na której operacje mogą być wykonywane przez bezpośrednie wywołania, to brzmi sensownie.

1

sztuczny klucz główny typu autoinc jest w 99% przypadków dobrym pomysłem w każdej tabeli (można się zastanawiać nad tabelami słownikowymi). Na danych, które mają być unikalne można założyć indeks unikalny.

1

Z drugiej strony: można też zrobić ładne DELETE /api/players/1/memberships/2 ;-)
(choć sam pewnie stworzyłbym sztuczny id w tym wypadku)

0

@somekind: @Patryk27 W tym przypadku też? Problem z zaprojektowaniem ścieżek w API Mam na myśli ReviewLike. Co prawda nie jest agregatem (root), ale jest encją.

0

No, ale jest oddzielnym bytem, czy jest elementem nadrzędnego bytu? Bo jeśli to drugie, to raczej tak jak @Patryk27 pokazał.

0

@somekind: Czym dla Ciebie jest oddzielny byt? Aggregate Rootem?

0

Myślę, że każdy AR na pewno jest oddzielnym bytem, ale niekoniecznie w drugą stronę.

0

To kiedy w takim razie encja jest niezależnym bytem?

0

W większości przypadków z elementów klucza złożonego da się wygenerować jedną wartość i używać jej jako identyfikatora w API. To na co moim zdaniem warto zwrócić uwagę, to czy pola tego klucza nie niosą przypadkiem wartości biznesowej. Jeżeli tak jest to moim zdaniem dołożenie własnego klucza głównego, pozbawionego jakiegokolwiek związku z wartościami biznesowymi jest obowiązkowe.

0

Czyli że np. tworzymy obiekt {PlayerId = 1, TeamId = 1}, serializujemy do JSONa, a potem kodujemy Base64URL?

1

To jest dość grube podejście. Prościej np napisać sobie jakieś wyrażenie typu:
PlayerId*1e6+TeamId. Pytanie powinno raczej brzmieć, jaki masz powód dla stosowania klucza złożonego? Jeżeli nie walczysz z jakimiś replikacjami i problemem unikalności kluczy w systemie rozproszonym, to zwyczajnie daj z defaultu w każdej tabeli zwykłego autoinc'a - koszt bliski zeru, zapytania pisze się dużo prościej i jest to dużo czytelniejsze dla innych.

1 użytkowników online, w tym zalogowanych: 0, gości: 1