[h3lloya]

Wyobraźmy sobie sytuację w której administrator serwisu randkowego dodaje do bazy danych np cechy osobowości, a użytkownik podczas rejestracji wybiera, które z wymienionych cech dotyczą jego osoby. I teraz pytanie jak należy taką sytuację odzwierciedlić w bazie danych. Czy:
a) stworzyć osobną tabelę w której połączymy id użytkownika z id cechy osobowości
b) dodać dużą liczbę kolumn w tabeli z użytkownikami z miejscem na id cechy i liczyć na to, że ich liczba wystarczy

Nie mam na co dzień do czynienia z projektowaniem baz danych, więc może jest dla takiej sytuacji jeszcze inna wersja c?

#programowanie #bazydanych

[Kamyki_w_bucie]

@h3lloya: a

[M4ks]

@h3lloya: zalezy co dokladnie potrzebujesz i ile jest np. cech

[D.....r]

@h3lloya: we wprost masz artykuł o tym (cechach osobowości obu stron w związku na zasadzie przyznawania punktów jak w RPG, czyli nie możemy każdej maxa przyznać, jest 5 takich istotnych cech). Bardzo fajny artykuł "matematyka miłości".

[n.....y]

@h3lloya: Poczytaj o relacji Many-To-Many :D

[andrut1291]

Tworzysz tabelę która zawiera Id użytkownika i Id cechy

[Ozzfest]

@h3lloya: typowa relacja wiele do wielu. Zrób tabele z id cechy i id użytkownika.

[J.....n]

@h3lloya:
jeśli nie masz wypisanych cech jakie chcesz mieć w bazie trudno powiedzieć o architekturze
być może niektóre cechy będą hierarchiczne i wtedy przyda się relacyjność bazy

[legolass]

@h3lloya: Tabela na użytkowników, tabela na cechy, tabela na powiązanie. Pamiętaj o indexach

[h3lloya]

@Kamyki_w_bucie: dzięki

@M4ks: Liczba cech zależy od administratora. Można ze sporym prawdopodobieństwem określić górny limit np. 100, ale używanych będzie powiedzmy 5, więc drugie rozwiązanie wydawało mi się mało praktyczne.

@Donk_von_Fisher: przedstawiona sytuacja jest w całości wymyślona na potrzebę pytania :)

@nienarodzony: tzn wiem co to many-to-many, ale ponieważ nie siedzę w bazach to myślałem, że może lepsze mechanizmy się wykształciły w międzyczasie :)

@andrut1291: dzięki

@

[moon5]

"Wyobraźmy sobie sytuację w której administrator serwisu randkowego..."

Najlpiej nie tworzyć takich serwisów, bo potem są złamane serca. ( ͡° ͜ʖ ͡°)

[fenix7557]

A co myślicie o flagach? W tabeli user dać jedno pole "cechy", a w tabeli z cechami dać idcechy oraz nazwe, tylko idcechy musiałoby być potęgą dwójki.
Czyli np takie cechy: 1 xxx, 2 yyy, 4 zzzz, 8 hhhh, 16 pppp, 32 dddd

User Mirek miałby cechy xxx, yyy, ppp więc 1 + 2 + 16 = 19. Taka liczba w jego polu.

[m504]

@h3lloya: Generalnie to jak przedmówcy powyżej wybierz opcje (a). Opcji (b) nigdy nie bierz, niektóre bazy mają ograniczoną liczbę kolumn.

Gdy używasz bazy #postgresql i potrafisz zadać sam o spójność danych to możesz użyć innych rozwiązań:
c) Użyć array i w niej trzymać idki osobowości (lub lepiej ich nazwy)
d) Użyć zamiast tablicy typu jsonb
e) Nawet możesz użyć nieeleganckiego rozwiązania ze zwykłem polem tekstowym i oddzielonymi spacjami nazwami cech

W

[plushy]

@fenix7557: Nie kombinuj, bitmaski się składuje jako bit stringi a nie numerki. Poza tym nie to nie jest dobre rozwiązanie jeśli nie potrzebujemy wydajności.

[legolass]

@fenix7557: Wtedy wybranie użytkowników mających cechę x jest bardzo obciążające.

[fenix7557]

@legolass: Hm racja, nie wziąłem pod uwagę SELECTowania userów WHERE cecha coś: SELECT * FROM users WHERE cecha & id_cechy
Ale serio to takie obciążające? Nie próbowałem operacji bitowych w SQL. Problemem też zapisać te cechy w osobnej tabeli jako ID potęga dwójki. Chyba że dałoby się normalnie ID rosnąco zapisać i przeliczać na potęgę dwójki ale nie chce mi się rozkminiać tego.

[legolass]

@fenix7557: Trzeba przetestować możliwe rozwiązania i sprawdzić, ale skoro tych cech będzie około 100 to moim zdaniem nie trzeba się bawić w żadne bitmapy.

Jeszcze można rozważać np HStore w PostgreSQL i trzymanie tych cech jako słownika.

[Ragnarokk]

@h3lloya: Single Responsibility Principle. Tylko a