-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Can Burak Cilingir
Sent: Sat 12/17/2005 10:12 AM
To: [email protected]
Cc: cs-discuss
Subject: Re: [cs-lisp] RE: Another programming challenge - Re: [cs-discuss]PHP+MySQL versus Lisp: Shortest Path problemi ile ilgili -
Emre Sevinc wrote:
[ ... ]
>> This was a lovely feature. Believe me. People liked it.
>
>i was in love with that since Orkut.
>
Another research subject for psychology.
>> Now, people and the programmer are sorry. Why? Because
>> the aforementioned contacts table (I've given an example
>> in my previous mail, you can see it below, just includes
>> an ID and ContactID) has grown bigger. It's now about 5 MB.
>> cember.net became popular, more than a few thousand members.
>>
>There is an another problem here. That path calculation is not required
>to be done in real time! ( that's a design decision ( ? :) ) )
>it could be done daily and with some more clever decisions like "has any
>member added any member as a contact, regenerate the path, else use
>cached version".
The problem is that, you have to do it real time. What are you
going to cache? Every possibility? Every day, every minute new members
come, they connect to someone, then they click on a member that
they are not directly connected to in order to see their connection
path, if any. And they want to see the correct answer.
This is not about *my* connection list. I'm directly connected to them.
The path is clear.
The problem is that the question is asked all the time by the new users
which means new IDs. Any new or any old user may wish to see if they
are connected to any user. Think about number 1000 and feel the combinatorial
explosion deep in your soul. Are you going to generate a path
for me, a path in which I'm connected to user A, user B, ... , userZeta
(let's say in some way I'm connected to 500 hundred users out of 1000). Are you
going to calculate and store the results for me and 500 hundred people
(because I may wish to examine all of them). And same thing for the remaining
999 people. And we're talking about 1000. Make it a 10.000 (not a big number
for a popular site) and cover your ears in order not to hear the explosion.
But then, maybe you'll propose to buy another machine, replicate
the database and let that machine work like hell to calculate all
possible connections' paths and store them and do that everyday
for a few thousand users.
If you be more clear about what kind of a caching scheme you intended
then I can understand better. Maybe I misunderstood the deal.
Emre Sevinc
_______________________________________________ cs-lisp mailing list [email protected] http://church.cs.bilgi.edu.tr/lcg http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
