steve
i'm happy to hear your optimism, handling billions of rows sounds
amazing. but i'd like to be fully assured.
a frequent use of the table will perform selects that show:
a) people you have seen
b) people you haven't seen yet
an average user will quite quickly build a list of thousands of people
he has seen, so you will get selects like:
select * from user where id not in ( [list of seen users] ) and [other criteria]
how many users -- and simultaneous users -- can a normal mysql server
handle just fine when you've got people doing selects like this quite
often if not "all the time"?
On 12/07/07, Steve Edberg <[EMAIL PROTECTED]> wrote:
Well, one would assume not everyone knows everyone else. So you have
a People table (1,000 records in your example) and a Friends table
that looks something like
PersonId
FriendId
both of which are foreign keys pointing to the People table (which
would normally have an autoincremented primary key). Perhaps you
could include a 'quality of friendship' column as well. Even if you
had a party of 1,000 people where everyone knew everyone, a table of
1 million records is pretty reasonable. It all depends on your query
& index design (make friends with the EXPLAIN command). If you go
through the mailing list archives, you'll find numerous people with
multiple tables with billions of records.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
