Probably through standard database table normalisation.
Wherein there's one table that as all of the registered users in it.
Then, in another table, there'd be a listing for that particular user and all of their friends.
So let's just use simple values.
Table 1 (Schools):
SchoolID | SchoolName
1 | University of Whatever
2 | Whatever College
3 | Whatever University
Table 2 (Students):
StudentID | SchoolID | StudentName
1 | 1 | John Doe
2 | 1 | Jane Doe
3 | 2 | Stan DeMan
4 | 3 | Joe Blow
5 | 1 | Yadda Yadda
6 | 2 | Humpty Dumpty
7 | 3 | Jack Sprat
Table 3 (Friends):
FriendsID | StudentID | FriendID
1 | 1 | 2
2 | 1 | 5
3 | 3 | 6
4 | 4 | 7
In table 3, the friends are linked through the StudentID and FriendID through foreign keys.
So, in this case, John Doe has Jane Doe and Yadda Yadda listed as his friends.
Stan DeMan has Humpty Dumpty as his friend.
Joe Blow has Jack Sprat listed as his friend.
If you notice on their site, it states that you can only setup friends who attend your own school, so John Doe can't have Jack Sprat listed as his friend.
Having not written the site, I can only speculate, but that's probably close to what they're doing. Or, they could be storing arrays as you asked, so instead of individual listings for John Doe, it could be one listing with all of his friend's IDs in a stored array, but that's not the most efficient way to do it, and can be rather difficult to search through. A properly normalised and indexed table will output results very quickly. (At least, that's how I see it going down)
