В чем сложность структуры социальной сети

Почему говорят, что сложно построить таблицу для друзей?
Просто составить таблицу, в которой будет три столбца - id, friend_id_1, friend_id_2. И исключить по одной строке из пар, где значения второго и третьего полей равны. Для 250 000 пользователей, даже если они будут все друг с другом дружить, то получиться около 250 000 000 000 байт, 250 Гб. (три столбца который хранят от 1 до 250000 это где-то по 2,5 байта для одного столбца. 8*250000*250000/2 = 4* 625 * 100 000 000 = 250 000 000 000).
Получается на это хватит одного винчестера.
Сделать эту таблицу меньше наверное нельзя. Какие тогда оптимизации или нормализацию можно придумать еще.
Или сложность проектирования табли для социальной сети состоит в чем-то другом?

Можно. Первое поле не нужно.

-----
PostgreSQL DBA

для этого вам потребуется 18бит (2 в 18степени). делаем простой подсчет:
250000*18*2=9 000 000бит=1125000байт=1.07288361Мб.
поправьте меня если я не прав

-----
if(time()>1356048000) die();

White
Так нет, а там же нужно 250 000 * 250 000, т.е. каждый из них дружит с каждым. Максимальное число.
(Добавление)
Мелкий
А таблица без первого ключа, это значит что не primary key, а к такой таблице можно select делать? Зачем кстати primary key вообще нужен? Просто то что он есть это значит что таблица нормализована, но зачем он сам по себе нужен? Кроме случаев когда это например id пользователя, который нужен чтобы его запомнить в сессии и чтобы он менше места занимал. И чтобы по нему можно было найти точно пользователя потому что имя может повторятся у разных пользователей.

(Отредактировано автором: 17 Августа, 2011 - 20:04:19)

prog90 да, ошибся, только 250 000 * 250 000 будут две одинаковые пары. так что 250 000 * 250 000 / 2, и в итоге:
250 000 * 250 000 * 18 / 8 / 1 024 / 1 024 / 1 024 = 130.967237 (Гб)
для 2 полей.
первичный ключ тут ни к чему, каждая пара будет уникальной.

-----
if(time()>1356048000) die();

prog90, PK (primary key) на 2 поля, так же известный, как составной ключ.


Ни в коем случае. PK не ведёт к нормализации. Нормализация ведёт к созданию PK.
PK позволяет однозначно идентифировать строку в таблице. Всё.


Запросто. Ещё и быстрее инсерты проходить будут, т.к. индексы перестраивать не нужно. А вот выборки пострадают.

-----
PostgreSQL DBA

А что дает составной ключ? Он упрощает написание запроса SELECT? Или что он дает. Просто по id можно найти типа select .... where id = 3; А составной ключ что даст?

При составном ключе на friend_id_1, friend_id_2 смысла в id нет никакого.


Однозначно укажет на where friend_id_1=10 and friend_id_2=20
В общем, курите маны на реляционные базы данных. А потом на EXPLAIN SELECT

-----
PostgreSQL DBA

Т.е. позволит быстрее найти пару friend_id_1, friend_id_2? Первичный ключ похож на индекс?

Как это нет? А удалить/удалиться из друзей?

-----
Шта? Репозиторий?

DeepVarvar WHERE friend_id_1=... AND friend_id_2=...

-----
if(time()>1356048000) die();

Аааа черт... Сплю еще - почему-то спящий мосх подумал про сообщухи и их удаление и хитрым нейронным способом прикрутил эту часть осознания к списку фройндов...
Пойду кофейку намучу...

-----
Шта? Репозиторий?