Я собственно в своем способе и пытаюсь уйти от множества таблиц к одной :) А вы наоборот возвращаетесь к множеству. А почему вы хотите делать именно через таблицу wall_element? Пускай все лежит в одной таблице. Просто ваш способ сильно увеличивает нагрузку на БД, усложняет запросы и не сильно упрощает работу.
"+" моего
1)1 таблица, один запрос на всю стену при выводе + шардинг. Очень легкий и быстрый запрос. Уменьшается нагрузка на БД. Я думаю база вполне долго сможет держать нагрузку при такой архитектуре, хоть до 100 млн пользователей.
2)легко изменять тело записи на стене
3)одинаково выводятся и обрабатываются как посты с одними фотографиями, так и только текстовые, аудио, так и смешанные. Все унифицировано.
4) Красиво на мой взгляд)
5) Упростит поиск(если вы захотите его добавить)
"-"
1)сложнее в реализации
2)данные дублируются во многих местах(это на самом деле нормально)
wall_record_content действительно дублирует некоторые записи из таблиц images, videos и т.д. Это нормально, в условиях больших данных нормализация не нужна. Данные должны дублироваться во многих местах. Жесткие диски стоят дешевле оперативной памяти. Нет ничего зазорного в том, что некоторые записи содержат в себе части других записей из других таблиц. Так работают все соц сети.
По похожему принципе вам следует сделать и друзей, и личные сообщения. и новости aka «social activity stream». Иначе при росте вас завалит.
А как сделать через wall_element вам предложили выше. Можно конечно попробовать составить запрос без джойнов, но он будет довольно длинный.
Тут все упирается в нагрузку, если у вас она пока небольшая, и пользователей немного то можете сделать через джойны, как вам предложили выше. Шардинг тоже пока не потребуется. Но в конце-концов вы упретесь в производительность БД и запросы будут выполняться очень долго. Один из альтернативных способов я предложил в своем первом ответе.
Но если проект станет большим, то рано или поздно вам придется перейти на другой способ и снова все переделывать.
Могу предложить 2 варианта:
1) Завести отдульную шарду и в ней хранить только таблицы user_id, email и password, например по миллиону таких записей в одной таблице,(таблиц может быть несколько) при логине подключаться только к этой БД, и в цикле по всем таблицам искать емайл и пароль, возвращать id пользователя и дальше уже использовать только его. Вариант костыльный и не самый лучший.
2) Придумать или найти алгоритм получения хеша email-а, чтобы формула давала идентификатор шарды, в которой хранятся данные пользователя { int(hash(«email@mail.com»)) mod количество шард }
Я думаю продублировать в каждой шарде, чтобы можно было забрать инбокс пользователя одним простым select-ом в из его шарды. Хранить придется в 2 раза больше данных, но в данном случае скорость важнее.
Я бы сделал так:
Завел бы дополнительную структуру вида user_id: shard_id, где shard_id — идентификатор базы данных в которой хранятся данные о пользователе(в нашем случае — сообщения)
Далее у нас появится некоторое количество баз данных, например, 100, каждая из которых хранит данные о 50 пользователей, в каждой такой базе данных есть таблица messages, в которой находятся сообщения пользователей, в итоге в каждой такой таблице будет находится не более миллиона записей. Теперь нам остается только узнать к какой БД нужно подключиться чтобы считать данные, для этого надо чтобы структура user_id: shard_id была доступна из любой точки приложения. Оптимальнее всего будет закэшировать её в памяти каждого сервера.
Попробую опровергнуть некоторые нападки этого джентльмена, вызванные отсутствием опыта использования Iphone в течение продолжительного времени.
1) Samsung Galaxy S3 весит почти столько же сколько и Iphone 4s, разница в пару грамм. Все аппараты этого класса весят примерно одинаково Так что заявление, что это кирпич, мягко говоря удивляет. Насчет краев, тут все довольно субъективно, лично мне удобно.
2)Доступ к основным настройкам, таким как включение Wi-fi, 3g, или режим «в самолете» можно получить просто потянув за статус бар, оттуда выедет панель быстрого доступа.
3) Обычно вместе 7 рабочих столов используют папки. Например, у меня 3 рабочих стола — на первом находятся приложение, которые я использую каждый день, на втором папки с приложениями, которые используются не так часто, а на третьем — приложения, которые запускаются очень редко. Так что это уже вопрос к владельцу, как он использует возможности своего телефона и свое время.
Виджеты — действительно удобная штука, которой иногда не хватает на ios, но не критичная. (хотя использовать их, чтобы мониторить карму O_o).
Хотя в любом случае, выбирая между Galaxy S3 и iPhone, не прогадаете. Оба смартфона хорошие, разве что у Galaxy больше возможностей для кастомизации. Другие android смартфоны такого же класса лично не использовал, только слышал от друзей, что заводскими прошивками пользоваться невозможно, и каждый месяц кто-нибудь да перепрошивает. Хотя они те еще гики :)
В iPhone меня все устраивает, ничего плохого сказать не могу. Что касается itunes, то не подключался к нему уже очень давно, если что-то надо передать, то использую облачные хранилища. Музыку и фильмы на iPhone не слушаю и не смотрю. Пользоваться просто, комфортно и приятно. Эта ос мне кажется удобнее чем Andriod(для справки — имеется планшет на Andriod).
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
