Re: Thinking about sorting articles..

[Rick James]

"a column for each possible category id" -- No! This is unmaintainable -- you will have to ALTER TABLE when you add a new category tomorrow. If you limit yourself to 64 categories, you could use the bits in a BIGINT UNSIGNED. Better yet would be a separate table with

article_id, category_id, timestamp
INDEX(category_id, timestamp) -- for ordered lookup
INDEX(article_id) -- for deleting (if needed)

Purists will cringe at my suggestions of redundant (denormalized) data. But they have not scaled very far. If you only get a few thousand comments, the details won't matter. If you get millions, performance considerations outweigh purity of schema.

You may need to bump a counter in the member table whenever an article come in (again redundant info). Or you could daily count how many there are, storing the info in a "summary" table with
member_id, date, ct
INDEX(member_id, date) -- if your query becomes
SELECT SUM(ct) ... WHERE member_id = 123 AND date BETWEEN...
To top off the count, you could add to that
SELECT COUNT(*) FROM articles WHERE datetime > CURRENT_DATE() AND member_id = 123;
That would need
INDEX(member_id, datetime)

Etc, etc. Munch on those for awhile, then we can discuss further. Next time, present the SHOW CREATE TABLE and tentative SELECTs. Be prepared for me to rip then to shreads and give you some more ideas.
;)