Създаване на по-усъвършенстван модел със статуси на потребител, нишка и публикация

В първата си статия за онлайн форум споменах, че може да има още няколко разширени функции за добавяне:

• Още официални подробности за потребителя вместо едно поле „име“. Може да искате името, фамилията и потребителското име или псевдоним на потребителя. Един хубав форум също така би позволил на потребителите да имат профилна снимка, имейл, роли, статус (за да позволи на потребителите да бъдат блокирани) и друга информация, като например кога последно са посетили форума.
• Допълнителен контрол, свързан с създаването на потребител за да можем да проследим кога е създаден нов потребител, но преди имейл адресът му да бъде потвърден.
• Категории на форума и подкатегории, където всяка категория има тема, няколко модератора и допълнителна информация като дата на създаване на категорията. Тема за публикация в допълнение към съдържанието
• Модерирани публикации които трябва да бъдат одобрени от модератор, преди да бъдат видими за други потребители. Публикациите и нишките биха имали различни състояния като:чакат за публикуване, публикувани, докладвани като спам, блокирани, отблокирани.
• И тогава може да искаме да позволим на потребителите да гласуват игласувайте против теми и публикации.

За форума ще използвам термина „нишка“, за да обознача разговор с потенциално няколко публикации, свързани с темата.

Ще направя начален коментар; Обикновено използвам кръгли числа като 100 или 1000, за да дефинирам дължината на полетата на varchar; Не предполагам, че те са непременно подходящия размер, но използвам това като стенография, вместо да оставя дължината недефинирана (%). От друга страна, понякога използвам много специфични дължини за полета като email и ip_address; 254 е максималната дължина, която един имейл адрес може да бъде според дефинициите на RFC, докато 45 е максималната дължина, която може да бъде един IPv6 адрес.

Подробности за потребителя

В част 1 от нашата поредица от статии за изграждане на онлайн форум информацията за потребителите беше много ограничена. Ще подобря данните за потребителя, които се съхраняват. Засега модерирането ще бъде много основно:потребителите ще бъдат или модератори, или не. По-късно може да създадем по-сложни правила за модериране, свързани с категории и теми.

За състоянието на потребителите ще създам user_status таблица, за да мога да я използвам повторно в друга ситуация, дори ако има много малко състояния, като „EMAIL_NOT_VERIFIED“, „VERIFIED“ и „BLOCKED“.

Създаване на потребител

Ще използвам статуса на потребителя, за да разпознавам потребители, които са в състояние „EMAIL_NOT_VERIFIED“, след като потребителят е създал своя акаунт и е изпратен имейл до дадения му имейл адрес, но преди да са щракнали върху URL адреса за потвърждение в имейла. Може дори да станете по-сложни и да имате състояния като „EMAIL_VERIFICATION_TO_BE_SENT“ и „EMAIL_VERIFICATION_RESENT“, ако някои от тези стъпки се обработват от различни компоненти във вашата система, а не веднага по време на създаването на потребител.

Състояния на нишки и публикации

Модерираните публикации трябва да бъдат одобрени от модератор, преди да бъдат видими за други потребители. Публикациите и нишките ще имат различни състояния като:чакат одобрение, одобрени, докладвани като спам, блокирани. За състоянието на нишките и публикациите ще избера по-гъвкав начин за справяне със статусите чрез връзка към status маса. Тогава приложението трябва да знае какво означава всяка стойност в таблиците на състоянието (ако status =„Одобрен“, нишката се показва), но предпочитам това пред просто съхраняване на текст в thread и post маси. Ще имаме няколко състояния, като „WAITING_FOR_APPROVAL“, „ОДОБРЕН“, „ОТКЛЮЧЕН“, „REPORTED_AS_SPAM“ и „BLOCKED“ и може да искаме да добавим още в бъдеще.

С други думи, потребителят създава нова нишка или нова публикация и тя се поставя в състояние „NOT_APPROVED“. Неодобрените теми и публикации не се показват на повечето потребители; модераторите обаче могат да видят неодобрени елементи и да изберат „Одобряване“ или „Отхвърляне“. Потребителите могат да маркират тема или публикация като спам, но това трябва да бъде потвърдено от модератор. Темите за спам и публикациите не се показват на потребителите.

Това ми позволява да използвам status таблица както за теми, така и за публикации, тъй като статусите и за двете трябва да имат едно и също значение. Няма да използвам неправилно status таблица за показване на статуса на потребителите; Не мисля, че това би било добър избор за дизайн.

Официален дизайн

И така, ние разширяваме ERD, който беше създаден в част 1. Оцветих таблиците, които бяха създадени в статията част 1, в жълто и оцветих новодобавените таблици в оранжево, така че да е по-лесно да видите допълненията. Въпреки това не съм маркирал отделни промени в таблиците.

Какво следва?

Отново има още допълнителни подобрения, които трябва да бъдат направени, но тук взехме много прост онлайн форум и добавихме няколко полезни нови функции.

В следващите части ще разгледам добавянето на други функции като:

• форумкатегории и подкатегории, където всяка категория има тема, няколко модератора и допълнителна информация като дата на създаване на категорията. Атема за постит в допълнение към съдържанието
• и тогава може да искаме да позволим на потребителите да гласуват и да гласуват за нишки и публикации.

Какви функции изисква вашият онлайн форум? Има ли някакви функции, които искате да взема предвид при подготовката на следващата част от тази поредица? Ако е така, уведомете ме.