Грамотная структура базы для хранения голосов

[Miracle]

Как грамотно организовать структуру MySQL базы для хранения информации для:
есть сайт, скажем фотосайт со множеством фотографий
пускай их в базе будет 1 млн.
есть пользователи на сайте, их скажем 100 тыс.

пользователи могут голосовать за фотографии
если все пользователи проголосуют за все фотографии то имеем 100 млн. голосов

надо организовать базу грамотно так чтобы скрипт как можно быстрее мог смотреть голосовал ли конкретный пользователь за конкретную фотографию и если да то повторый голос не засчитывать

у меня два способа как это организовать
первый
два стобца
user_id | photo_id
и так для каждого голоса прописывать новую запись
и того в нашем примере получаем 100 млн. записей

стрёмный способ

способ второй
два стобца
user_id | array_photo_id
то есть если пользователь хотя бы один раз за какую-то фотку проголосовал то для него создалась запись
user_id | array_photo_id
и уже для последующих его голосов в столбец array_photo_id добавлять новые photo_id скажем через запятую

и потом уже при проверки забирать весь масив и скажем смотреть через in_array есть ли уже такой photo_id или нет

если кому нарвится второй способ то каком виде лучше хранить столбец array_photo_id?
как text или что посоветуете?
всё-таки это массив будет очень большим если скажем пользователь сделал 100 тыс. голосов или даже 1 млн.

или кто что посоветует
какие другие есть способы для реализации данной задачи?

[Меняздесьдавнонет]

стремный способ.

[Miracle]

Готов выслушать любые предложения
вплоть даже до того, чтобы кто-то привёл причины почему не стоит хранить все голоса до бесконечности!

кстати, забыл упомянуть что у первого способа есть один большой плюс
скажем при удалении фотографии можно легко и быстро удалить и все её логи по голосам из базы чтобы её не загромождать и к тому же нам эти логи больше не понадобяться

со вторым же способом это тоже сделать реально
но уж больно муторно и долго

[Miracle]

RomikChef:
стремный способ.

в смысле ты предлагаешь выбрать первый вариант?
я вот тоже к нему склоняюсь

[Forza]

Miracle:
в смысле ты предлагаешь выбрать первый вариант?
я вот тоже к нему склоняюсь

самое главное - не забывать про индексирование!

[Miracle]

Forza:
самое главное - не забывать про индексирование!

конечно
это самособой разумеющееся

[Forza]

Miracle:
конечно
это самособой разумеющееся

Тогда только стрёмный способ. Второй не отвечает теории реляционных БД.

[Miracle]

Спасибо большое!

[Miracle]

вот тут проблема возникла
остановимся на первом способе

и так, какие действия мы будем делать с этой информацией?
1. смотреть есть ли записи user_id | photo_id
если есть то не позволяем голосовать
для быстрого нахождения используем multipile_column_indexes
так как это быстрее в случаем поиска сразу по двум параметрам
(а ведь мы помним что при наших идеальных условиях у нас 100 млн. записей)
и так как повтор user_id в десять раз будет встречаться чаще чем photo_id (соотношение 100 тыс. к 1 млн. при наших идеальных условиях 1/10) то нам выгодней выставить крайним левом префиксом столбец user_id
так и поступаем

2. если вдруг ник пользователя надо удалить из базы, то ради рациональности мы удаляем и все логи по голосованию данного пользователя
и тогда опять возвращаемся к нашего логу голосований
DELETE FROM voted_photos WHERE user_id = \'$user_id\';
и всё отлично, при поиске нужных строк будет использован индекс

3. нам надо удалить фотографию в том числе её инфо из логов голосований
DELETE FROM voted_photos WHERE photo_id = \'$photo_id\';
но вот беда
при той структуре индексов что мы создали в данной ситуации индексы не будут использованы
вот тут вся проблема

и так вопрос:
как всё таки в данной ситуации лучше сделать индексы
1. сделать раздельные индексы
отдельно user_id и отдально photo_id
но тогда мы будем терять в скорости при самой популярной операции обращения (проверки на существования user_id & photo_id)
2. сделать многостолбцовый индекс для user_id & photo_id и ещё сделать один раздельный индекс для photo_id
но тогда файл индексов будет значительно больше
а отсюда и сложность с ним работать
ну и конечно немного дольше будет заноситься новая информация так как надо создавать больше индексов

или может ещё какие варианты есть?
хотелось бы послушать

[Меняздесьдавнонет]

вообще никаких индексов не делать

[Miracle]

RomikChef:
вообще никаких индексов не делать

какие плюсы?

[Phoinix]

Miracle

2. сделать многостолбцовый индекс для user_id & photo_id и ещё сделать один раздельный индекс для photo_id
но тогда файл индексов будет значительно больше
а отсюда и сложность с ним работать
ну и конечно немного дольше будет заноситься новая информация так как надо создавать больше индексов

интересно в чем сложнось???

Зачем тебе индексы, если у тебя в таблице 2 поля, оба из которых индексные? У тебя индекс будет просто дублировать таблицу... а скорость - никакой скорости...

А причем здесь PHP???

[Miracle]

Phoinix:
интересно в чем сложнось???

база будет тяжелей

Phoinix:
У тебя индекс будет просто дублировать таблицу

ну я с планами на будущее
я ещё не уверен что будет только user_id и photo_id
вот всё думаю стоит ли добавить ещё пару полей
таких как какую именно оценку пользователь поставил и время когда он это сделал
просто может в будущем если уж слишком база будет большая то к примеру время голосования использовать для того что голоса старше к примеру двух месяцев удалять

вот такие дела

Phoinix:
А причем здесь PHP???

я думал на эту тему
но решил всё таки продолжить всё в этом топике
изначально запостил сюда так как думал что много предложений будет как с php всё это грамотно сделать

[Меняздесьдавнонет]

а какие минусы?

[Miracle]

RomikChef:
а какие минусы?

ну если в таблице будут не только user_id и photo_id
а ещё два столбца
то ведь минусы есть?
в быстродействии поиска или как?
выгодней сделать иедксы по второму варианту что я описал выше