Какая схема MySQL была бы оптимальной для этого типа системы - PullRequest
Новая
       1

Какая схема MySQL была бы оптимальной для этого типа системы

0 голосов
/ 13 сентября 2010

Предполагается, что система похожа на Netflix, где участники создают список желаемых фильмов и, в зависимости от типа плана, один, два или более фильмов в своем списке превращаются в заказы, что делает одну из следующих схем более смысл?

  1. Таблица управления, в которой хранятся следующие столбцы:

    элементы управления (memberid, currentMoviesAtHome, moviesAtHomeLimit, currentMonthlyMovies, ежемесячныеMoviesLimit)

Пользователь фактически не решает, когда будет создан заказ, поскольку это зависит от контроля его учетной записи. Ежедневная функция будет проходить через клиентов и их элементы управления и выбирать тех, где currentMoviesAtHome < moviesAtHomeLimit AND currentMonthlyMovies < monthlyMoviesLimit ...

  1. Отдельная таблица accounts, связанная с таблицей plans планов:

    учетных записей (memberid, planid, currentMoviesAtHome, currentMonthlyMovies)

    планы (planid, фильмы AtHomeLimit, ежемесячные фильмы MovieLimit)

Ответы [ 2 ]

2 голосов
/ 13 сентября 2010

Второй вариант, имеющий таблицы ACCOUNTS и PLANS, нормализован, поэтому я рекомендую его.

Кроме того, эти таблицы:

  • MOVIES
  • WISHLIST
    • movie_id (первичный ключ, внешний ключ к MOVIES.movie_id)
    • account_id (первичный ключ, внешний ключ к ACCOUNTS.account_id)
    • is_onsite

is_onsite будет логическим, чтобы определить, был ли фильм отправлен клиенту.Если это так, значение должно быть установлено на 1. Используйте это для суммирования, чтобы узнать, находится ли учетная запись на уровне или ниже их предела плана.Когда видео возвращено, удаляйте только те строки, для которых is_onsite имеет значение 1.

0 голосов
/ 13 сентября 2010

Ежедневная функция будет проходить через клиентов и их элементы управления и выбирать

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

Ежедневный опрос не будет масштабироваться.

Выстрел и обработка события будут не только быстрее, но и легче поддерживаться в долгосрочной перспективе.Удачи.

...