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?
No jeśli to jakaś encja, na której operacje mogą być wykonywane przez bezpośrednie wywołania, to brzmi sensownie.
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.
Z drugiej strony: można też zrobić ładne DELETE /api/players/1/memberships/2
;-)
(choć sam pewnie stworzyłbym sztuczny id w tym wypadku)
@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ą.
No, ale jest oddzielnym bytem, czy jest elementem nadrzędnego bytu? Bo jeśli to drugie, to raczej tak jak @Patryk27 pokazał.
@somekind: Czym dla Ciebie jest oddzielny byt? Aggregate Rootem?
Myślę, że każdy AR na pewno jest oddzielnym bytem, ale niekoniecznie w drugą stronę.
To kiedy w takim razie encja jest niezależnym bytem?
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.
Czyli że np. tworzymy obiekt {PlayerId = 1, TeamId = 1}
, serializujemy do JSONa, a potem kodujemy Base64URL?
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.