Теперь насчет 2 вопроса, как я уже писал у меня есть id_users(id пользователей через запятую) по сути это id тех пользователей которым этот пост добавлять не нужно(оно у них уже как бы есть). Я прописываю эти id через запятую в поле поста(таблица всех постов). Этих id в этом поле огромное кол-во(longtext).
И при определенном действие мне как бы необходимо разослать это сказание в ленты моим друзьям как бы, но только тем которых нет в этом списке id конкретного поста. Для начала я выбираю моих друзей, и можно делать запрос в mysql и делать через кучу LIKE то есть если друзей тыс 5 то соответственно столько же и операторjв LIKE, или можно выбрать это поле и через массив определить имеется ли в нем id моих друзей.
Это был первый вариант.
Теперь второй, это делать таблицу связки, где id_user(это id кому не надо рассылать пост), и id_post(для связи с таблицей постов). Но там строк будет в несколько сотен раз больше чем постов. (примерно тыс 50-100 на запись) И при этом придется делать очень много запросов к этой таблице, выбрав друзей потом делать запросы к этой таблице(примерная сложность n(кол-во друзей)). Хочется услышать Ваше мнение по этой проблеме...
в конце концов кому не нравятся большие таблицы в Mysql партицирование есть
Я ничего не имею против большой таблицы, меня волнует производительность выборки из нее. И если Вы говорите что тысячи открывания таблиц будет - плохо, то буду делать с большой таблицей и выборка по индексу. (Добавление)
Хотя может, если создавать таблицу для потов где-то около месяц или чуть меньше. То есть каждый месяц своя таблица, так сказать немного разбивать данные по времени. Как думайте скорость выборки увеличится? Так как чем меньше данных в таблице тем вроде должно быть по лучше... (Добавление)
Цитата:
Mysql партицирование
Думаю это то что нужно, но на данном этапе пока буду пользоваться 1 таблицей, а как данных будет много то можно будет заняться партицированием.
Спс caballero.
Ну и что? Какая проблема-то? Все вторичные индексы innoDB ссылаются на первичный ключ, и отлично живут весьма огромные таблицы.
Конечно mysql будет работать с таким кол-во данных, я собственно не об этом. Я опять же по скорости работы, выбирать из одной таблицы где огромное число строк по индексу(id_user) или же по отдельно таблице просто и без индекса. И велика ли разница? (Добавление)
Цитата:
В отсутствии будущего и ужасных костылей тут же, как понадобится любая агрегация. А она понадобится. Иметь проект и даже представления не иметь о происходящих там делах - невозможно.
Это Вы что сейчас имеете ввиду?
И еще по поводу таблиц, если я не ошибаюсь то время выполнения запроса на выборку постов определенного пользователя(по индексу id_user) будет зависеть от кол-во записей в общем в это таблице постов. А если по отдельным таблицам, то будет зависеть от кол-во записей только конкретного пользователя. Я прав?
Мелкий, Возможно я некорректно задал вопрос, попробую задать конкретнее.
Где-то читал тут на форуме мельком что Вы изучали реляционную модель данных - это очень хорошо. 1 вопрос - почти часть второго... Как Вы считаете индивидуальную таблицу постов для каждого пользователя. Для поиска записей не по 1, а без него, простой вывод с таблицы. Как я уже писал записей ожидается много, и конечно меньше их не будет... Или Вы считаете что неважно сколько записей будет в таблице, по 1 индексу будет выбираться быстрее чем без него и по отдельной таблице? Или какие проблемы Вы видите в этой реализации? Также по логике чем больше этих данных в таблице тем и хуже будет выбираться из нее, хоть по индексу хоть как...
Смотря в каком случае, мне на данный момент волнует производительность того или иного варианта. Если с использованием индексов и отдельной таблицей, разница в производительности ничтожна то почему бы и нет. Ну а если разница все же есть, то тогда выберу в строну производительности.
Цитата:
- вывести ленту постов (опционально, друзей). Само собой, отсортированную по датам.
- активность пользователей за месяц, неделю
- вся агрегация данных, вся сортировка
Ну лично я решаю подобные проблемы с доп.функционалом потом, сначала сделав самое нужное. Ну а уже потом если нужно, то уже можно сделать...
Для такого чтобы использовать только 1 тока индекс(id_post), а выбирать все посты пользователя можно и без индекса так как отдельная таблица есть. Разве лучше когда 1 таблица и использовать 2 индекса, с большим объемом информации разве это лучше?
Ps Ну если б я рассчитывал тока на пару десятков тысяч, то я бы так и сделал, но если будет около 1 млн строк и более...
EuGen, эти id которые я прописывал через запятую, они были привязаны не к пользователя, а к посту, ну а сам пост естественно к пользователю, но для каждого пользователя у меня отдельная таблица постов. По этому выборка происходит по одному индексу. Поэтому я написал, что если создавать еще таблицу связки для каждого пользователя(чтобы не выбирать по 3 индексам, а по 2).
Самый корректный путь - создать таблицу-связку и определить внешний ключ на соответствующем информациооном поле. Если пытаться в реляционной СУБД нарушать законы реляционных БД, то правильной архитектуры не получится никогда.
Я уже думал о такой связке, но почему то не выбрал этот путь, ведь даже если для каждого пользователя создавать свою такую таблицу связку. Примерно около 50-100 тыс строк для одной записи в среднем. Даже если делать на все поля индексы(на id_post и user), то мне почему - то кажется что выборка с помощью этой табличке будет занимать весьма длительное время... Или я в чем - то ошибаюсь?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 808
