One to many vs Many to many - tags

pytanie zadane 9 kwietnia 2018 w SQL, bazy danych przez Anoonymous Obywatel (1,560 p.)

Zastanawiam się nad zastosowaniem odpowiedniej relacji w bazie i nie bardzo widzę plusy zastosowania (w moim przypadku!) many to many:

Chciałbym utworzyć tzw. Tagi jak na blogu gdzie jeden wpis może mieć ich wiele (jak np. działa to w wordpresie):

item: idItem | name ...

tags: idItem | tagName

W przypadku many to many wyglądałoby to tak:

item: idItem | name ...

tags: idTag | tagName

itemTags: idItem | idTag

Powiedzcie mi, czy w moim przypadku najlepszym wyjściem będzie zastosowanie relacji one to many (pierwszej)? Jeśli tak to kiedy dokładnie użyć many to many?

1 odpowiedź

odpowiedź 9 kwietnia 2018 przez Tomek Sochacki Ekspert (227,510 p.)
wybrane 9 kwietnia 2018 przez Anoonymous

Najlepsza

Jeden wpis może mieć wiele różnych tagów (np. JS, programowanie) i jednocześnie jeden tag może być przypisany do wielu wpisów (to chyba oczywiste :) także relacja wiele do wielu, z blokadą na unikalność pary id_wpisu - id_tagu.

Potem możesz sobie łatwo wyciągnąć to nawet w jednym rekordzie przy użyciu GROUP_CONCAT() lub w każdy inny sposób.

komentarz 9 kwietnia 2018 przez Anoonymous Obywatel (1,560 p.)

No tak, rozumiem to, jednak nie wiem czemu pierwszy sposób jest błędny - zakładając, że cala implementacja działa na backendzie i nie ma możliwości wybrania "błędnego taga".

Chcąc sprawdzić tylko jednego taga wystarczy, że zapytałbym baze jakie idItem jest dla tego tagName

komentarz 9 kwietnia 2018 przez Tomek Sochacki Ekspert (227,510 p.)

Sorki ale totalnie nie rozumiem :) Back-end nie ma tutaj nic o rzeczy, Twoje pytanie dotyczyło struktury bazy, a to co sobie back-end z niej wyciąga to zupełnie osobna bajka.

W bazie możesz np. potworzyć wiele róznych relacji i złączeń, a potem dane pobierać w prosty sposób chociażby z widoków, żeby już nie bawić się w skomplikowane selecty w kodzie aplikacji.

Zabezpieczenie na wypadek zdublowania tagu i tak uważam, że warto w bazie zrobić mimo wszystko.

Samą listę tagów i tak pobrałbym w tym wypadku wcześniej np. podczas tworzenia posta aby po prostu elegancko po pierwsze podpowiadać je userowi, a po drugie już na froncie ograniczyć możliwość zdublowania. Oczywiście front można zawsze zmodyfikować, dlatego w back-endzie warto przelecieć tagi, ale tutaj w sumie nie ma sensu już ładować zwrotnego info że np. coś jest zdublowane, tylko po prostu najzwyczajniej w świecie automatycznie usunąć duplikaty i w takiej formie ładować do bazy - a tam mimo wszystko ostatnia kontrola.

komentarz 9 kwietnia 2018 przez Anoonymous Obywatel (1,560 p.)
edycja 9 kwietnia 2018 przez Anoonymous

Użytkownik nie ma możliwości dodawania niczego - po prostu tym zajmuje się backend, który sam automatycznie dodaje treści bez interakcji z userem, czy frontem - to miałem na myśli pisząc o backendzie.

Dzięki za odpowiedź

komentarz 9 kwietnia 2018 przez Anoonymous Obywatel (1,560 p.)

EDIT: Pozwolisz, że dopytam: Posiadam na backendzie (celowo na backendzie, a nie w bazie ze względu na specyfikę) tablice z jedynymi dostępnymi tagami. Jak już wspolnialem user nie ma możliwości interakcji, aplikacja weryfikuje test i sama przydziela tagi określonemu elementowi. Czy proste: IdTag oraz nazwa nie byłyby zarówno łatwiejsze do implementacji jak i również późniejszej modernizacji? Wydaje mi się również, że many to many w tym przypadku jest mocno przesadzone - stąd mój temat. Czy przy takim założeniu mogę skorzystać z pierwszej opcji?

komentarz 9 kwietnia 2018 przez Tomek Sochacki Ekspert (227,510 p.)

Hmm, nie wiem co Ty tam kombinujesz, ale jak na moje to kompikujesz sobie życie mieszaniem zmiennych w backendzie z danymi w bazie.

Ja bym to zrobił tak, że po prostu zapisałbym w bazie danych tablicę z tagami, tablicę z postami i tablicę pośrednią post-tag. Następnie machnąłbym sobie widok w którym miałbym złączenie tagów i np. zgrupowanie ich GROUP_CONCAT() co potem umożliwia mi łatwe rozdzielenie np. na tablicę w JS (back i front robię u siebie w JS). Daje mi to też łatwiejsze operowanie na danych zwracanych z bazy - mniej rekordów do analizy.

Natomiast co do zapisu to po prostu dodałbym wpis, a nastepnie powiązał go z tagami w tablicy pośredniej. Widok w tym momencie sam się zaktualizuje.

Przed dodaniem wpisu w back-endzie można pobrać sobie listę wszystkich dostępnych tagów i wybierać z nich te, które w danej chwili potrzebujesz. Możesz pobrać sobie np. dla każdego tagu jego id i nazwę, wszystko zależy od tego co dokładnie chcesz robić i jak je analizować.

Szczerze mówiąc to nie rozumiem w ogóle sensu robienia tu relacji innej niż wiele do wielu.

Co więcej, takie rozwiązanie pozwala Ci łatwo analizować np. najczęściej używane tagi itp.