Database
 sql >> Baza danych >  >> RDS >> Database

Tworzenie bardziej zaawansowanego modelu ze statusami użytkownika, wątku i postu

W moim pierwszym artykule o forum internetowym wspomniałem, że można dodać kilka bardziej zaawansowanych funkcji:

  • Więcej formalnych informacji o użytkowniku zamiast pojedynczego pola „nazwa”. Możesz chcieć podać imię, nazwisko i nazwę użytkownika lub pseudonim użytkownika. Ładne forum pozwoliłoby również użytkownikom na posiadanie zdjęcia profilowego, adresu e-mail, ról, statusu (aby umożliwić blokowanie użytkowników) i innych informacji, takich jak data ostatniej wizyty na forum.
  • Dodatkowa kontrola związana z tworzeniem użytkownika abyśmy mogli śledzić, kiedy tworzony jest nowy użytkownik, ale zanim jego adres e-mail zostanie potwierdzony.
  • Forum kategorie oraz podkategorie, w których każda kategoria ma temat, kilku moderatorów i dodatkowe informacje, takie jak data utworzenia kategorii. Temat postu oprócz treści
  • Wpisy moderowane które muszą zostać zatwierdzone przez moderatora, zanim będą widoczne dla innych użytkowników. Posty i wątki miałyby różne statusy, takie jak:oczekujące na publikację, opublikowane, zgłoszone jako spam, zablokowane, odblokowane.
  • A potem możemy zezwolić użytkownikom na głosowanie i zagłosuj wątki i posty.

Na forum będę używał terminu „wątek”, aby odnieść się do rozmowy z potencjalnie kilkoma wpisami związanymi z wątkiem.




Zrobię wstępny komentarz; Zwykle używam okrągłych liczb, takich jak 100 lub 1000, aby określić długość pól varchar; Nie sugeruję, że są to koniecznie odpowiednie rozmiary, ale używam tego jako skrótu, zamiast pozostawiać nieokreśloną długość (%). Z drugiej strony czasami używam bardzo konkretnych długości dla pól takich jak email i ip_address; 254 to maksymalna długość, jaką może mieć adres e-mail zgodnie z definicjami RFC, podczas gdy 45 to maksymalna długość, jaką może mieć adres IPv6.

Szczegóły użytkownika

W części 1 naszej serii artykułów na temat tworzenia forum internetowego informacje o użytkownikach były bardzo ograniczone. Ulepszę przechowywane dane użytkownika. Na razie moderacja będzie bardzo podstawowa:użytkownicy będą albo moderatorami, albo nie. Możemy później stworzyć bardziej skomplikowane zasady moderacji związane z kategoriami i wątkami.

Dla statusu użytkowników utworzę user_status tabeli, abym mógł ponownie użyć jej w innej sytuacji, nawet jeśli jest bardzo mało statusów, takich jak „EMAIL_NOT_VERIFIED”, „VERIFIED” i „BLOCKED”.

Tworzenie użytkownika

Użyję statusu użytkownika, aby rozpoznać użytkowników, którzy mają status „EMAIL_NOT_VERIFIED” po utworzeniu przez użytkownika konta i wysłaniu wiadomości e-mail na podany przez niego adres e-mail, ale zanim klikną weryfikacyjny adres URL w e-mailu. Możesz nawet stać się trudniejszy i mieć statusy takie jak „EMAIL_VERIFICATION_TO_BE_SENT” i „EMAIL_VERIFICATION_RESENT”, jeśli niektóre z tych kroków są obsługiwane przez różne komponenty w twoim systemie, a nie od razu podczas tworzenia użytkownika.

Statusy wątków i postów

Posty moderowane muszą zostać zatwierdzone przez moderatora, zanim będą widoczne dla innych użytkowników. Posty i wątki miałyby różne statusy, takie jak:oczekujące na zatwierdzenie, zatwierdzone, zgłoszone jako spam, zablokowane. W przypadku statusu wątków i postów wybiorę bardziej elastyczny sposób radzenia sobie ze statusami, łącząc się z status stół. Następnie aplikacja musi wiedzieć, co oznacza każda wartość w tabelach stanu (jeśli status =„APPROVED”, wątek jest wyświetlany), ale wolę to po prostu przechowywać tekst w thread i post tabele. Będziemy mieć kilka statusów, takich jak „WAITING_FOR_APPROVAL”, „APPROVED”, „REJECTED”, „RAPORTED_AS_SPAM” i „BLOCKED”, a w przyszłości być może będziemy chcieli dodać więcej.

Innymi słowy, użytkownik tworzy nowy wątek lub nowy post i otrzymuje status „NOT_APPROVED”. Niezatwierdzone wątki i posty nie są wyświetlane większości użytkowników; jednak moderatorzy mogą przeglądać niezatwierdzone elementy i wybrać „Zatwierdź” lub „Odrzuć”. Użytkownicy mogą oznaczyć wątek lub wpis jako spam, ale musi to zostać potwierdzone przez moderatora. Wątki i posty ze spamem nie są wyświetlane użytkownikom.

To pozwala mi używać status tabela dla wątków i postów, ponieważ statusy dla obu powinny mieć to samo znaczenie. Nie będę nadużywać status tabela do wskazania statusu użytkowników; Nie sądzę, żeby to był dobry wybór projektowy.

Projekt formalny

Rozszerzamy więc ERD, który został utworzony w części 1. Pokolorowałem tabele utworzone w artykule części 1 na żółto, a nowo dodane tabele pokolorowałem na pomarańczowo, aby łatwiej było zobaczyć dodatki. Nie zaznaczyłem jednak poszczególnych zmian w tabelach.



Co dalej?

Ponownie, wciąż trzeba wprowadzić dodatkowe ulepszenia, ale tutaj wzięliśmy bardzo proste forum internetowe i dodaliśmy kilka przydatnych nowych funkcji.

W kolejnych częściach przyjrzę się dodawaniu innych funkcji, takich jak:

  • forum kategorie oraz podkategorie, w których każda kategoria ma temat, kilku moderatorów i dodatkowe informacje, takie jak data utworzenia kategorii. Temat za post oprócz treści
  • a następnie możemy zezwolić użytkownikom na głosowanie na wątki i posty oraz głosowanie na nie.

Jakich funkcji wymaga Twoje forum internetowe? Czy są jakieś cechy, które chciałbyś, abym wziął pod uwagę przygotowując kolejną część tej serii? Jeśli tak, daj mi znać.

« Poprzednia część Następna część »


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Jak uruchamiają się plany równoległe – część 5

  2. Model danych agencji nieruchomości

  3. Tworzenie kopii zapasowych i przywracanie bazy danych z obsługą FILESTREAM

  4. Uruchomienie bazy danych RAC kończy się niepowodzeniem z błędem ORA-12547

  5. Filtrowanie danych za pomocą JDBC RowSet