Dalam artikel pertama saya tentang forum online, saya menyebutkan bahwa mungkin ada beberapa fitur yang lebih canggih untuk ditambahkan:
- Lebih banyak detail formal tentang pengguna alih-alih satu bidang "nama". Anda mungkin menginginkan nama depan, nama belakang, dan nama pengguna atau nama panggilan pengguna. Forum yang bagus juga memungkinkan pengguna untuk memiliki gambar profil, email, peran, status (untuk memungkinkan pengguna diblokir), dan informasi lain seperti kapan terakhir kali mereka mengunjungi forum.
- Kontrol tambahan yang terkait dengan pembuatan pengguna sehingga kami dapat melacak ketika pengguna baru dibuat tetapi sebelum alamat emailnya dikonfirmasi.
- Forum kategori dan subkategori di mana setiap kategori memiliki subjek, beberapa moderator, dan informasi tambahan seperti tanggal pembuatan kategori. Subjek untuk postingan selain konten
- Postingan yang dimoderasi yang harus disetujui oleh moderator sebelum dapat dilihat oleh pengguna lain. Pos dan utas akan memiliki status yang berbeda seperti:menunggu publikasi, dipublikasikan, dilaporkan sebagai spam, diblokir, tidak diblokir.
- Kemudian kami mungkin ingin mengizinkan pengguna untuk memberikan suara dan tidak memilih utas dan postingan.
Untuk forum, saya akan menggunakan istilah "utas" untuk merujuk pada percakapan dengan beberapa postingan yang berpotensi terkait dengan utas.
Saya akan membuat komentar pembuka; Saya biasanya menggunakan angka bulat seperti 100 atau 1000 untuk menentukan panjang bidang varchar; Saya tidak menyarankan bahwa ini adalah ukuran yang sesuai, tetapi saya menggunakan ini sebagai singkatan, daripada membiarkan panjangnya tidak ditentukan (%). Di sisi lain, saya kadang-kadang menggunakan panjang yang sangat spesifik untuk bidang seperti email dan ip_address; 254 adalah panjang maksimum alamat email menurut definisi RFC, sedangkan 45 adalah panjang maksimum alamat IPv6.
Detail Pengguna
Di Bagian 1 dari seri artikel kami tentang membangun forum online, informasi pengguna sangat terbatas. Saya akan meningkatkan detail pengguna yang disimpan. Untuk saat ini, moderasi akan sangat mendasar:pengguna akan menjadi moderator atau tidak. Kami mungkin akan membuat aturan moderasi yang lebih rumit terkait kategori dan rangkaian pesan nanti.
Untuk status pengguna, saya akan membuat user_status tabel, sehingga saya dapat menggunakannya kembali dalam situasi lain meskipun statusnya sangat sedikit, seperti “EMAIL_NOT_VERIFIED”, “VERIFIED”, dan “BLOCKED”.
Pembuatan Pengguna
Saya akan menggunakan status pengguna untuk mengenali pengguna yang berstatus “EMAIL_NOT_VERIFIED” setelah pengguna membuat akun dan email telah dikirim ke alamat email yang diberikan, tetapi sebelum mereka mengklik URL verifikasi di email. Anda bahkan bisa menjadi lebih rumit dan memiliki status seperti “EMAIL_VERIFICATION_TO_BE_SENT” dan “EMAIL_VERIFICATION_RESENT” jika beberapa langkah ini ditangani oleh komponen yang berbeda di sistem Anda dan tidak segera selama pembuatan pengguna.
Status Utas dan Pos
Postingan yang dimoderasi harus disetujui oleh moderator sebelum dapat dilihat oleh pengguna lain. Posting dan utas akan memiliki status yang berbeda seperti:menunggu persetujuan, disetujui, dilaporkan sebagai spam, diblokir. Untuk status utas dan posting, saya akan memilih cara yang lebih fleksibel untuk menangani status dengan menautkan ke status meja. Kemudian aplikasi harus tahu apa arti setiap nilai dalam tabel status (jika status =“DISETUJUI”, utas ditampilkan), tetapi saya lebih suka ini daripada hanya menyimpan teks di thread dan post tabel. Kami akan memiliki beberapa status, seperti “WAITING_FOR_APPROVAL”, “APPROVED”, “REJECTED”, “REPORTED_AS_SPAM”, dan “BLOCKED”, dan kami mungkin ingin menambahkan lebih banyak lagi di masa mendatang.
Dengan kata lain, pengguna membuat utas baru atau posting baru, dan dimasukkan ke dalam status “TIDAK_TERSEDIA”. Utas dan pos yang tidak disetujui tidak ditampilkan kepada sebagian besar pengguna; namun, moderator dapat melihat item yang tidak disetujui dan memilih "Setuju" atau "Tolak". Pengguna dapat menandai utas atau posting sebagai spam, tetapi itu harus dikonfirmasi oleh moderator. Utas dan pos spam tidak ditampilkan kepada pengguna.
Ini memungkinkan saya untuk menggunakan status tabel untuk utas dan posting, karena status keduanya harus memiliki arti yang sama. Saya tidak akan menyalahgunakan status tabel untuk menunjukkan status pengguna; Menurut saya itu bukan pilihan desain yang bagus.
Desain Formal
Jadi, kami memperluas ERD yang dibuat di Bagian 1. Saya telah mewarnai tabel yang dibuat di artikel Bagian 1 dengan warna kuning dan mewarnai tabel yang baru ditambahkan dengan warna oranye sehingga lebih mudah untuk melihat penambahannya. Namun, saya belum menandai perubahan individual dalam tabel.
Apa Selanjutnya?
Sekali lagi, masih ada perbaikan tambahan yang harus dilakukan, tetapi di sini kami telah mengambil forum online yang sangat sederhana dan menambahkan beberapa fitur baru yang berguna.
Di bagian selanjutnya, saya akan melihat menambahkan fitur lain seperti:
- forum kategori dan subkategori di mana setiap kategori memiliki subjek, beberapa moderator, dan informasi tambahan seperti tanggal pembuatan kategori. Subjek untuk pos selain konten
- lalu kami mungkin ingin mengizinkan pengguna untuk memilih dan menolak rangkaian pesan dan postingan.
Fitur apa yang dibutuhkan forum online Anda? Apakah ada fitur yang Anda ingin saya perhitungkan saat menyiapkan bagian selanjutnya dari seri ini? Jika demikian, beri tahu saya.
| « Bagian Sebelumnya | Bagian Selanjutnya » |
