C****n
发帖数: 2324 | 1 I mean the READ/NOREAD status.
The system remember the read/noread status for every user/every articles, I
just feel it's kindof impossible.
I guess we have 2000 users. Let's say we have up to 100 discussion board, and
there're up to 10,000 articles in every board. (Actually, shopping board
already has more than 9,000 articles). If we use a table like UserID/ArticleID
to track the status, it just seems amazing to me, because there's gonna be
about 2000 X 10000 X 100 = 2,000,000,000 records in th | b****e
发帖数: 1275 | 2 i don't think tehy need to use userid/articleID. if you know how newsgroups
tracks what articles you read, it's only one row per userid/board. all the
unread articles separated by commas form the one column of unread_articles
【在 C****n 的大作中提到】
: I mean the READ/NOREAD status.
: The system remember the read/noread status for every user/every articles, I
: just feel it's kindof impossible.
: I guess we have 2000 users. Let's say we have up to 100 discussion board, and
: there're up to 10,000 articles in every board. (Actually, shopping board
: already has more than 9,000 articles). If we use a table like UserID/ArticleID
: to track the status, it just seems amazing to me, because there's gonna be
: about 2000 X 10000 X 100 = 2,000,000,000 records in th
| C****n
发帖数: 2324 | 3 Sounds good, but there're more than 9000 articles in Shopping board.
So the column will in size of 9000X4 = 36k, maybe we'll have to make it 50k.
Is this too big?
But it's a good solution then, I am wondering the speed to join the article
table with the this status table.
Thanks,
I
and
UserID/ArticleID
【在 b****e 的大作中提到】
: i don't think tehy need to use userid/articleID. if you know how newsgroups
: tracks what articles you read, it's only one row per userid/board. all the
: unread articles separated by commas form the one column of unread_articles
| b****e
发帖数: 1275 | 4 no, they can use 34-50,52,60-75
【在 C****n 的大作中提到】
: Sounds good, but there're more than 9000 articles in Shopping board.
: So the column will in size of 9000X4 = 36k, maybe we'll have to make it 50k.
: Is this too big?
: But it's a good solution then, I am wondering the speed to join the article
: table with the this status table.
: Thanks,
:
: I
: and
: UserID/ArticleID
| C****n
发帖数: 2324 | 5
What does this mean?
And if a column is too big, it has to be in text mode, and text can't be used
to compare using "like something%...'.
Thanks,
Calvin
50k.
article
newsgroups
the
unread_articles
【在 b****e 的大作中提到】
: no, they can use 34-50,52,60-75
| a*****a
发帖数: 438 | 6 but what if my unread articles are 3,6,9,...,3n? it'll taken even bigger
column because you need to say: 1-2,4-5,7-8... instead of 3,6,9.
【在 b****e 的大作中提到】
: no, they can use 34-50,52,60-75
| b****e
发帖数: 1275 | 7 statistically this is a small-probability event. how many users leave
their boards with Ns scattered all over the place?
this, by the way, is also known as run-length encoding
【在 a*****a 的大作中提到】
: but what if my unread articles are 3,6,9,...,3n? it'll taken even bigger
: column because you need to say: 1-2,4-5,7-8... instead of 3,6,9.
| a*****a
发帖数: 438 | 8 ok, that makes sense.
so i guess they store this read/unread information like this:
0xff, 0x00, 0xff, 0x1 (ie. 255 read, 255 unread)
【在 b****e 的大作中提到】
: statistically this is a small-probability event. how many users leave
: their boards with Ns scattered all over the place?
: this, by the way, is also known as run-length encoding
|
|
