[franczi]

#bazydanych #sql #java #programowanie
Mam aplikację webową, która pozwala użytkownikowi dodawać, edytować, usuwać, wyświetlać różne obiekty. Aplikacja jest oparta na springu, obiekty przechowywane są w bazie danych. Do bazy łączę się za pomocą jednego konta. W jaki sposób najlepiej zrealizować dostęp użytkownika tylko do jego danych? Widzę dwie opcje, pierwsza to klucz obcy do tabeli z użytkownikami w każdej tabeli powiązanej z obiektami z aplikacji, a druga to pole, w którym przechowuję username właściciela danego wiersza. Oba rozwiązania sprowadzają się do dodania odpowiednich warunków w zapytaniach po stronie backendu. Oba są w sumie podobne, pytanie, która opcja jest lepsza? Z relacjami czy bez? Jeżeli mają być relacje, to jak to ogarnąć na diagramie ERD? Im więcej typów obiektów będę dokładał (a są one często ze sobą powiązane) tym większy miszmasz mi się zrobi. W ogóle to czy jest jakieś modelowe podejście? Szukam od jakiegoś czasu ale ten temat wydaje mi się przemilczany, lub ja szukam pod złym hasłem ( ͡° ͜ʖ ͡°)

[s.....a]

@franczi: dodałbym tabelę users

[s.....a]

@franczi: tym bardziej, że jak są użytkownicy, to chyba muszą sie jakoś logować

[franczi]

@slucham-psa-jak-gra: No jest tabela users

[s.....a]

@franczi: no to klucz obcy

[s.....a]

@franczi: nie ma sensu powielać danych w bazie

[m.....g]

@franczi: Wszystko jest sztuką kompromisu. Jeżeli to jest mała aplikacja i nie masz problemu z wydajnością to oczywistym wyborem jest tabela users i klucz obcy. Przy dużej skali trzeba niestety stosować denormalizację danych, ponieważ operacje JOIN zabijają bazę. Wtedy trzymanie nazwy użytkownika przy każdym wierszu może nie jest najlepszym pomysłem, ale jeżeli w scopie requesta lub sesji przechowujesz id użytkownika, to spokojnie można użyć tego id.

[franczi]

@manjag: Docelowo będzie max 15 tabel, w których będę musiał wiedzieć, kto jest właścicielem wiersza.

[kemek]

@franczi: Możesz jeszcze dodać tabelę, która będzie trzymała właścicieli wierszy (przy takim podejściu łatwo to rozszerzyć do wielu właścicieli jednego wiersza).
id-właściciela (fk), id-obiektu-z-tab1 (fk), id-obiektu-z-tab2 (fk), id-obiektu-z-tab3 (fk)... itd. W jednym takim wierszu tylko jedna kolumna id-obiektu-z-tab nie jest nullem.

Z diagramem przy każdym podejściu będzie sieczka. Najlepiej wydzielić "kopię", który tylko ilustruje relacje "własności" wierszy.