Здравствуйте, уважаемые программисты. Я новичек в php и начал делать свой первый сайт - социальную сеть. Знаю, что выбрал не самую легкую задачу, но тем не менее. В интернете очень много об этом написано, но так же много и всего мусора. Поэтому, если вам не сложно, накидайте пару ссылок. Как у меня реализовано: Архитектура: в корневом каталоге лежат три папки: lib site sys В lib находятся css, js, шаблоны шапки и меню и некоторые картинки. В site лежит сам сайт. Там есть такие папки, как profile, friends, mail и так далее. Сделано это для того, чтобы человек, зайдя, например, в профиль, перешел по ссылке http://somesite.com/profile/. Все функциональные php-фалы лежат в папке processing. Например, добавление в друзья происходит через /site/friends/processing/add_friend.php В sys находятся классы, функции и так далее. БД Есть глобальная таблица users, в которой есть поля mail, password, id. При регистрации создаются отдельные таблице: user_profile_id, user_mail_id, user_friends_id, причем в конце каждой таблици добавляется id пользователья. Мне на одном ресурсе сказали, что это не правильнои что надо читать про нормализацию данных. Хотел бы услышать мнения умных и опытных людей.
Вот честно - ты не обижайся, но звучит как-то смешно. Целые команды опытных специалистов борятся и совершенствуют свои соц.сети. А тут вдруг пришёл ты )) Конечно, если чисто в учебных целях - то почему бы и нет. Ну да ладно, это всё не по теме и вообще извини, может ты ещё фейсбук переплюнешь и будешь потом хвастаться посещалкой. Глобальная таблица? А это как? По-моему, бред. Я, конечно, социальные сети не писал, но думаю, что не нужно создавать новые таблицы. При регистрации нужно добавлять данные в уже существующие. И, я полагаю, обычным MySQL (в случае успеха проекта) ты не отделаешься. Придётся изучать всякие там Redis и memcashed... Но вообще, если действительно, вопреки всему, это будет соц.сеть и люди начнут ей пользоваться - ну, во-первых, радуйся. А во-вторых - там многие проблемы уже по-другому решаться будут. Дешевле купить новый мощный сервер, чем перелопатить код. Да и всякие Redis уже изучать будет нужно не тебе, наверно, а кому-то из команды тех.поддержки проекта )) Фейсбук изначально писался практически "на коленке". Я думаю, он и сегодня весь кривой, но масть пошла
А куда тогда совать сообщения? Друзей? В одной таблице вряд ли все поместится. Не хочу на коленке писать. Хочу наиболее правильнее сделать. И спасибо за ответ!
Ну, допустим, есть таблица users. В ней есть user_id (идентификатор пользователя). Тогда друзья - можно сделать так, например: Код (Text): +---------+----------------+-----------------+ | user_id | friend_user_id | friendship_date | +---------+----------------+-----------------+ | 1 | 2 | 2011-01-01 | | 1 | 3 | 2011-03-04 | | 2 | 5 | 2011-02-15 | | 2 | 19 | 2011-02-11 | | 2 | 11 | 2011-12-20 | +---------+----------------+-----------------+ Но это так, просто пример... По сообщениям - так, например Код (Text): +--------------+------------+------------------+ | from_user_id | to_user_id | message | +--------------+------------+------------------+ | 1 | 2 | Привет! | | 2 | 1 | Ну, здарова! :-) | +--------------+------------+------------------+
Ну а если у меня будет 10 тысяч пользователей, и у каждого по 100 друзей? Тогда в таблице будет около 100 тысяч строк как минимум.
В принципе, возможно ты и прав. Даже, скорей всего прав. Я же говорю - соц. сети не писал. Но 100 000 строк - это фигня для любой субд. И миллион - тоже фигня. Если есть индексы, если поиск, выборки - по целочисленным ключам... Но вообще, огромное кол-во таблиц - это, скорее всего, тоже не очень хорошо. Труднее админить, труднее и более ресурсоёмко статистики всякие считать, наверно, проблематичнее бекапами заниматься. Я писал (и, надеюсь, ещё буду писать) сайты с довольно большой посещаемостью, с огромным количеством данных, одновременное кол-во запросов к сайту в секунду - десятки, бывало и поболее сотни. Рекордов я даже не знаю, не отслеживал как-то. При этом там были таблицы в десятки миллионов строк. Выборки шли, в основном по целочисленным проиндексированным полям. Сайт ни разу не упал из-за перегрузок. Просто достаточно мощный выделенный сервер, правильно настроенный.