сложный выбор дизайна таблицы mysql

Question

Я разрабатываю довольно сложную базу данных и борюсь с выборами по одному аспекту. Пользователи могут загружать видео, фотографии и истории, некоторые бесплатные, некоторые другие участники будут платить. Фотографии должны быть сгруппированы в наборы с именем.

Я уже решил добавить в колонку базы данных членов, представляющую «количество бесплатных наборов фотографий», «количество платных фото-наборов»; то же самое для видео и рассказов.

Решение, с которым я борюсь, заключается в хранении заданных имен, номеров в каждом наборе и типе набора.

Пожалуйста, имейте в виду, что если множество фотографий имеет 6 в этом, я буду должен показать соответствующий 6. То же самое для видео и т.д.

Файлы будут сохранены с закодированными названиями - фото, userid 2, set 3, картинка 4 будет сохранена как FP020304.jpg (только пример), и именно так я буду знать, какие из них нужно вспомнить.

Выбор 1: Один дополнительный стол для каждого члена со следующими столбцами (представительном):

пример записи являются:

SET-ID | SetType | SetName | NumberInSet  
1  | freephotos | holiday | 10 
2  | paidphotos | birthday | 6 

---

Выбор 2: То же самое, но только одну таблицу для всех члены только с «MemberID», добавленным в столбцы

Выбор 3: одна таблица для каждого типа, для каждого участника, например, одна таблица для бесплатных фотографий, другая для платных и т. д.

Выбор 4: то же, что и 3, но с добавлением столбца идентификатора участника. (Только 6 таблиц)

Мышление до сих пор: Выбор 3 кажется проще всего делать запросы, но я не уверен, что мне нравится идея добавления 6 таблиц для каждого нового участника. Выбор 4 кажется наиболее логичным, так как будет только 6 таблиц, но извлечение соответствующей информации будет более сложным. Выбора 1 & 2 результата в менее новых таблицах на одного члена, но и, кажется хитрым получение результаты

Я не неблагоприятный для хитрых решений, однако я просто не могу решить, что будет лучше для этого сценария - на самом деле, я уверен, другие способы, о которых я еще не думал.

Предложения были бы весьма признательны.

(нб - первое сообщение - я надеюсь, что это выходит разборчиво)

Answer 1

Choice 3 ужасна, стереть его сейчас. Я также не советую хранить «число в наборе» в качестве значения в вашей базе данных. Каждый раз, когда вы вставляете новую фотографию, вам нужно будет обновить соответствующее значение numberinset. Решение для этого - не сохранять агрегированные значения в вашей базе данных, использовать агрегаты в сценариях, чтобы возвращать этот счет.

Я бы пошел с таблицей «участники» или «пользователи», таблицей «набор», которая связывает фото/видеоустановки с вашими пользователями (сюда можно добавить бесплатный/платный столбец). Оттуда создайте таблицу фото/файлов, которая связывает фотографии с таблицей «set». Количество фотокопий/Vidoe х в каждом наборе могут быть определены

select set_id , count(1) from mediatable group by set_id 

Это даст вам, что число в заданном значении и вам не придется беспокоиться об обновлении столбца «Count», как это.

Answer 2

Не создавать новые таблицы для каждого пользователя, вы просто хотите один. Кроме того, я бы не назвал файлы с закодированным заголовком, это упростит для ботов или других пользователей поэтапно идти, хотя файлы, если они знают схему, вместо этого просто сохраняют путь к файлу и используют случайное сгенерированное имя или хэш. Не забудьте установить Foreign Keys и Indexes, чтобы ускорить JOINS, и любой поиск, который вы сделаете.

SetTypeTBL - SetTypeID, SetTypeName

SetTBL - SetID, SetTypeID, MemberID, SetName

MediaTypeTBL - MediaTypeID, MediaTypeName

MediaTBL - MediaID, MediaTypeID, SetID, MemberID, MediaName, MediaFilePath