Pytanie projekt bazy danych dla "obserwatorów" i "obserwatorów"?


Drodzy eksperci / programiści baz danych:

Mam tabelę mysql z informacjami o użytkownikach, takimi jak

id      user_id         name etc.
1       userA            
2       userB   
3       userC
..      ..
..      ..

Chcę utworzyć funkcję podobną do 'follow' innych użytkowników, takich jak twitter. UżytkownikA może śledzić użytkownika B lub użytkownik B może śledzić użytkownika A lub obie mogą śledzić się nawzajem. W tym celu powinienem utworzyć 1 tabelę, powiedzmy obserwatorów

id      user_id     follower_id
1           userA       userB
2           userC       userA
3           userA       userC
4           userB       userC
5           userX       userA

Teraz chcę znaleźć, kto obserwuje użytkownikaA. Tak bym chciała: Wybierz * z obserwujących, gdzie user_id = userA Spowoduje to wybranie userB i userC. To jest to, czego potrzebuję.

Teraz chcę znaleźć, które osoby użytkownikA następuje (na przykład w powyższej tabeli, userA jest po userC i userX.) Następnie powinienem uruchomić coś podobnego Wybierz * z obserwujących, gdzie follower_id = userA.

Moje pytanie brzmi, czy ten projekt bazy danych jest poprawny dla tego problemu (biorąc pod uwagę nadmiarowość i optymalizację bazy danych?). Czy może być lepsze podejście niż to? Dzięki.


27
2018-02-04 08:07


pochodzenie


BTW, następującys jest źle - Mohammed Noureldin


Odpowiedzi:


Ogólnie twój projekt jest poprawny.

Ale jeśli user_id jest unikalny w tabeli "users", nie potrzebujesz kolumny "id" w "users". (Pojedyncza tabela zawierająca unikalny "identyfikator" i unikalny "user_id" jest dość nietypowy.) Nie potrzebujesz też kolumny "id" w tabeli "followers".

Klucz podstawowy w "obserwatorach" powinien być (id_użytkownika, id_połącznika) i upewnić się, że każda z tych kolumn ma klucz obcy odnoszący się do "user_id" w "użytkownikach".


12
2018-02-04 08:32





Ogólna wskazówka. Użyj liczb całkowitych do identyfikatorów, a nie do łańcuchów. Występuje znacząca różnica w wydajności. Upuść user.user_id i zmień nazwę users.id na users.user_id. Po drugie tablica twoich obserwujących powinna mieć indeksy na id_użytkownika i id_połącznika. Ponownie istnieje znacząca korzyść z wydajności. Podoba mi się również pomysł posiadania unikalnego indeksu na (id_użytkownika, follower_id), wywoływanie tego klucza podstawowego i upuszczanie kolumny id.


4
2018-02-04 08:33



Zgadzam się z twoim głównym punktem, że liczby całkowite są lepsze jako klucze podstawowe / obce. Ale myślę, że to, co nazwał user_idmoże to być coś w rodzaju "nazwy logowania" (i powinno to zostać poprawnie zmienione, ale nie usunięte), rzecz, która jest potrzebna i musi być unikalna w systemie. Wciąż follow tabela powinna używać liczb całkowitych, tak jak sugerujesz. - Andriy M


Tak, twój projekt jest zwykłym sposobem radzenia sobie z wieloma związkami. Wyszukaj "modelowanie wielu-do-wielu baz danych", a znajdziesz wiele zasobów podając przykłady tego.

Dodaj klucze obce z tabeli relacji do tabeli użytkowników.

Jeśli twój związek zawiera dodatkowe informacje, umieścisz to jako kolumnę w swoim łączącym stole. Może na przykład data, kiedy jeden użytkownik zaczął podążać inną.

Osobny klucz zastępczy w tabeli łączenia, taki jak dodana kolumna ID, może być przydatny, jeśli chcesz mieć inne tabele odwołujące się do twojego stołu.


1
2018-02-04 08:45





Oto mój projekt.

Id    userId(PK)  followerId     followedDate         unfollewedDate
1     123         456            YYYY-MM-DD HH:MI:SS  YYYY-MM-DD HH:MI:SS
...   ...         ...            ...                  ...

Założyłam identyfikator użytkownika - followerId combiacja jest wyjątkowa. Daty mogą być przydatne. Na przykład myślę o użyciu, jeśli użytkownik przestanie obserwować i powtórzy to za 5 minut, nie generuje powiadomień. Zakładam, że użytkownik zrobił to przez pomyłkę. I mogę analizować następujące statyki według daty.


1
2018-04-21 09:28