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.

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