MarkusM
Новичок
Нетривиальная задача (MySQL и PHP)
Всем, доброго времени суток.
Вот столкнулся с проблемой.
На сайте есть каталог статей. У каждой статьи есть заголовок, основной текст и анотация (остаьное не нужно для объяснения проблемы).
Анотация состоит из 10 уникальных предложений. Статьи разбиты по категориям (имеется отдельная таблица с категориями).
Хотим разадавать сайтам-партнерам листинг статей.
То есть партнер регистрируется и потом ему выдается список статей этой категории, с названием статьи и с анотацией.
Анотация состоит из трех предложений из тех 10 предложений которые прилагаются к статье.
По поводу анотации: мы генерируем 120 уникальных вариантов анотаций по три предложения. То есть в 120 вариантах, например, комбинация из 1,7 и 10 го предложения встречается только один раз.
Далее каждый партнер для каждой статьи получает рандомно один из 120 вариантов анотаций, причем этот вариант для данной статьи выдаваемой этому партнеру должен быть постоянным.
То есть номер этого варианта надо где-то хранить.
Далее, при отдаче партнеру листинга статей необходимо перемешать их, то есть назначить каждому партнеру свою сортировку вывода статей в листинге.
И эту сортировку для каждого партнера надо сохранить, она должна быть постоянной.
В принципе задачу вроде объяснил.
Как я сначала решил эту задачу:
Я создал таблицу ordering.
partnerID articleID variantID ordering
и таблицу summary_variants
variantID articleID summaryVariant
в эту таблицу я пишу автоинкрементов ID варианта анотации , ID статьи и один из вариантов анотации.
То есть в таблице для каждой статьи есть 120 строк.
в ordering в partnerID я писал ID партнера, в articleID писал ID статьи, в variantID рандомный ID варианта из 120 вариантов и в ordering порядок сортировки.
То есть в этой таблице для каждого партнера будет столько записей сколько имеется статей.
Теперь о проблемах. Все это прекрассно работает и не вызывает проблем. Но это только пока.
Как выяснилось количество статей будет свыше 60 000 тысяч. Ожидаемое кол-во партнеров 5 000 - 6 000, возможно больше.
То есть получаем для таблицы ordering 60000*6000-360 000 000 строк. Если перевести все это в kb, то очень много получается. В несколько раз больше максимального размера файла базы.
А значит этот вариант не годится. Мне тут предложили для каждого партнера создавать отдельную таблицу с ID партнера и в нее писать все что будем выдавать ему.
В этом случае увеличится скорость отдачи, но тогда в базе со временем будет столько таблиц, сколько будет партнеров.
Вот я теперь и зашел в тупик что делать. Что можете посоветовать? Может направите на путь истинный.
Всем, доброго времени суток.
Вот столкнулся с проблемой.
На сайте есть каталог статей. У каждой статьи есть заголовок, основной текст и анотация (остаьное не нужно для объяснения проблемы).
Анотация состоит из 10 уникальных предложений. Статьи разбиты по категориям (имеется отдельная таблица с категориями).
Хотим разадавать сайтам-партнерам листинг статей.
То есть партнер регистрируется и потом ему выдается список статей этой категории, с названием статьи и с анотацией.
Анотация состоит из трех предложений из тех 10 предложений которые прилагаются к статье.
По поводу анотации: мы генерируем 120 уникальных вариантов анотаций по три предложения. То есть в 120 вариантах, например, комбинация из 1,7 и 10 го предложения встречается только один раз.
Далее каждый партнер для каждой статьи получает рандомно один из 120 вариантов анотаций, причем этот вариант для данной статьи выдаваемой этому партнеру должен быть постоянным.
То есть номер этого варианта надо где-то хранить.
Далее, при отдаче партнеру листинга статей необходимо перемешать их, то есть назначить каждому партнеру свою сортировку вывода статей в листинге.
И эту сортировку для каждого партнера надо сохранить, она должна быть постоянной.
В принципе задачу вроде объяснил.
Как я сначала решил эту задачу:
Я создал таблицу ordering.
partnerID articleID variantID ordering
и таблицу summary_variants
variantID articleID summaryVariant
в эту таблицу я пишу автоинкрементов ID варианта анотации , ID статьи и один из вариантов анотации.
То есть в таблице для каждой статьи есть 120 строк.
в ordering в partnerID я писал ID партнера, в articleID писал ID статьи, в variantID рандомный ID варианта из 120 вариантов и в ordering порядок сортировки.
То есть в этой таблице для каждого партнера будет столько записей сколько имеется статей.
Теперь о проблемах. Все это прекрассно работает и не вызывает проблем. Но это только пока.
Как выяснилось количество статей будет свыше 60 000 тысяч. Ожидаемое кол-во партнеров 5 000 - 6 000, возможно больше.
То есть получаем для таблицы ordering 60000*6000-360 000 000 строк. Если перевести все это в kb, то очень много получается. В несколько раз больше максимального размера файла базы.
А значит этот вариант не годится. Мне тут предложили для каждого партнера создавать отдельную таблицу с ID партнера и в нее писать все что будем выдавать ему.
В этом случае увеличится скорость отдачи, но тогда в базе со временем будет столько таблиц, сколько будет партнеров.
Вот я теперь и зашел в тупик что делать. Что можете посоветовать? Может направите на путь истинный.
