ผมว่าวิธีนั้นก็ถูกแล้วนะครับ database 20000 item ก็ไม่เยอะนะผมว่า

อาจจะตั้ง service ขึ้นมาตัวนึงคอยกวาดเอาข้อมูลเก่า ๆ ออกไป มาร์คว่าเป็น read ก็ได้ถ้ากังวลว่ามันจะเยอะเกินไปน่ะครับ

ฐานข้อมูลมันก็ออกแบบให้รับข้อมูลอย่างนั้นอยู่แล้วนิ... ตั้ง index ดีๆ ก็ไม่ช้าแล้วล่ะ

ถ้าไม่ได้จะ query เอาเฉพาะที่ read หรือเฉพาะที่ unread ผมว่าเก็บใส่ใน table user เพิ่มไปอีก column ก็ได้นะครับ เป็นฟิลด์ read_items เก็บ id ของ item ที่อ่านแล้ว อาจจะเป็น CSV ก็ได้

ตอนแสดงผลค่อยเอามาเปรียบเทียบ อาจจะช้าหน่อยถ้ามีจำนวนเยอะๆ ซึ่งก็อาจจะตั้ง limit ไว้ว่าเก็บแค่ n item ล่าสุดก็ได้

แบ่ง Table ออกเป็นสองส่วนครับ ส่วนแรกใช้สำหรับ Front-End อย่างเดียว ไม่มีการ update มันจะเพิ่มความเร็วในการอ่านข้อมูลได้เยอะมาก และเราสามารถที่จะเลือกได้ว่า จะใช้ Table แบบใหน เช่น memcached (เอา Table สำหรับที่อ่านอย่างเดียวไปไว้บน memory)

หรือจะใช้ Database ที่มีความเร็วกว่า MySQL ก็ได้ครับสำหรับในส่วนที่ใช้ Read เช่น MongoDB

ส่วนที่ 2 ก็ใช้สำหรับการ update / insert อย่างเดียว

ถ้าแบ่งออกแบบนี้จะช่วยเรื่องของความเร็วได้เยอะครับ

ถ้าบอกว่าตาม webboard ผมเข้าใจว่า มันมอง index จาก reply เที่ยบกับที่ index reply ที่เคย read ครั้งล่าสุดเอานะ ถ้า index reply ไหนมากกว่า index ที่เคย read ก่อนหน้า มันก็จะทำตัวหนาให้ .... ที่คิดว่าเป็นยังงั้นเพราะว่าบางกระทู้ที่ผมยังไม่อ่าน แต่กลับมาอีกทีมันไม่เป็นตัวหนาให้ มีแต่กระทู้ที่มี reply เพิ่มจากครั้งก่อน ถึงจะขึ้นตัวหนา (อ้างอิงจากเวบ overclockzone นะครับ) .... ถ้าตามนี้ก็แต่ละ user มี field เดียวจบเลย =w=! (last_index < current_reply_index) แต่คิดไปคิดมา มันเอาไปใช้กับพวก feed ไม่ได้สินะ

เก็บเฉพาะที่อ่านแล้วดีกว่านะ เพราะถ้าเนื้อหาเยอะๆคงไม่มีใครนั่งอ่านกระทู้ซะทั้งหมดหรอก

สมมุติมี 1000 กระทู้ อ่านกระทู้เดียวก็เก็บตัวเดียว

ทำแบบ 2 ตาราง อันนี้ผมดันครับ
แต่.. อันนึงเป็น real table อันอันเป็น view table โดย ตอน Create View นั้นให้อ้างจาก list ของ user ทั้งหมดที่เข้าชม
ถ้า user ที่เข้าชม เคยเข้าดู topic นั้นๆ แล้วก็ ให้แสดง UI เป็นแบบ Read ครับ สามารถแก้ปัญหา Multi user ได้ด้วยนะครับ

ปล. ผมยังไม่เคยเลยทำนะครับ