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

Question

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

0

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

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

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

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

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

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

планы (planid, moviesAtHomeLimit, ежемесячноMoviesLimit)

Mohamad 13 сен. 2010, в 06:57

Источник

1

У вас нет другой таблицы, в которой перечислены фильмы, которые есть у пользователя, в том числе возвращенные за последний месяц? Вы бы предпочли SELECT COUNT(*) WHERE ... в этой таблице, чтобы определить currentMoviesAtHome и currentMonthlyMovies а не хранить отдельные значения, которые могут быть не синхронизированы?
Mike DeSimone 13 сен. 2010, в 04:34

Теги:

mysql

data-modeling

database-design

2 ответа

0

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

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

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

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

RibaldEddie 13 сен. 2010, в 02:23

0

Альтернативой является запуск логики при возврате фильма / элемента. Голосование не кажется таким уж плохим, когда это можно сделать один раз в день для этой ситуации, поскольку маловероятно, чтобы товар был возвращен и отправлен по почте следующему клиенту в течение дня. Это правдоподобно, но в качестве поставщика услуг вам нужна небольшая комната для маневра.
OMG Ponies 13 сен. 2010, в 04:30
0

@ Рибальд, использование этого подхода означает, что я должен проверять каждый раз, когда пользователь меняет свой список пожеланий / добавляет, удаляет элемент ... разве это не тратит ресурсы, если у пользователя уже есть его максимальные заказы? Какой смысл проверять, следует ли нам создавать заказ, когда у человека превышен лимит или уже открыто два заказа?
Mohamad 13 сен. 2010, в 05:06
1

Вам не нужно перепроверять, когда пользователь добавляет или удаляет элемент в своем списке желаний, так как изменение этой информации не меняет значение количества фильмов, которые они извлекли. OMG Ponies верна, вам нужно только проверять, когда вы собираетесь изменить рассматриваемые значения; т.е. когда фильм возвращается.
RibaldEddie 13 сен. 2010, в 05:32
0

Кроме того, вы можете подумать, что избегать опроса не стоит усилий или что оно каким-то образом ограничивает вас, но я скептически отношусь к этому, что приносит какую-либо выгоду.
RibaldEddie 13 сен. 2010, в 05:41
0

Спасибо за вклад! Я согласен с таким подходом, но меня немного смущает сценарий, когда кто-то регистрируется и в его списке ничего нет ... по определению, чтобы вычесть число из контрольной таблицы, нам нужно проанализировать таблицу списка желаний. Другими словами, как мы узнаем, когда кто-то впервые присоединяется, превращать ли что-то в своем списке желаний в порядок, не всегда анализируя эту таблицу ...
Mohamad 13 сен. 2010, в 23:27
0

Да, когда они регистрируются или имеют несколько пунктов в своем списке желаний, вам понадобится логика, чтобы справиться с этим. Вероятно, решение состоит в том, что более чем одно действие вызовет событие «выберите фильм в очередь для отправки по почте». Если вы простите мое понимание, если вы хотите улучшить свои навыки разработки, вы должны начать думать с точки зрения асинхронных программ, управляемых событиями. Это не просто вопрос масштабируемости, это также ядро поддерживаемого программного обеспечения. Это также улучшит ваши навыки и даст вам прочную основу, чтобы стать лучшим программистом.
RibaldEddie 14 сен. 2010, в 02:41

Показать ещё 4 комментария

Ещё вопросы

У вас нет другой таблицы, в которой перечислены фильмы, которые есть у пользователя, в том числе возвращенные за последний месяц? Вы бы предпочли SELECT COUNT(*) WHERE ... в этой таблице, чтобы определить currentMoviesAtHome и currentMonthlyMovies а не хранить отдельные значения, которые могут быть не синхронизированы?
Альтернативой является запуск логики при возврате фильма / элемента. Голосование не кажется таким уж плохим, когда это можно сделать один раз в день для этой ситуации, поскольку маловероятно, чтобы товар был возвращен и отправлен по почте следующему клиенту в течение дня. Это правдоподобно, но в качестве поставщика услуг вам нужна небольшая комната для маневра.
@ Рибальд, использование этого подхода означает, что я должен проверять каждый раз, когда пользователь меняет свой список пожеланий / добавляет, удаляет элемент ... разве это не тратит ресурсы, если у пользователя уже есть его максимальные заказы? Какой смысл проверять, следует ли нам создавать заказ, когда у человека превышен лимит или уже открыто два заказа?
Вам не нужно перепроверять, когда пользователь добавляет или удаляет элемент в своем списке желаний, так как изменение этой информации не меняет значение количества фильмов, которые они извлекли. OMG Ponies верна, вам нужно только проверять, когда вы собираетесь изменить рассматриваемые значения; т.е. когда фильм возвращается.
Кроме того, вы можете подумать, что избегать опроса не стоит усилий или что оно каким-то образом ограничивает вас, но я скептически отношусь к этому, что приносит какую-либо выгоду.
Спасибо за вклад! Я согласен с таким подходом, но меня немного смущает сценарий, когда кто-то регистрируется и в его списке ничего нет ... по определению, чтобы вычесть число из контрольной таблицы, нам нужно проанализировать таблицу списка желаний. Другими словами, как мы узнаем, когда кто-то впервые присоединяется, превращать ли что-то в своем списке желаний в порядок, не всегда анализируя эту таблицу ...
Да, когда они регистрируются или имеют несколько пунктов в своем списке желаний, вам понадобится логика, чтобы справиться с этим. Вероятно, решение состоит в том, что более чем одно действие вызовет событие «выберите фильм в очередь для отправки по почте». Если вы простите мое понимание, если вы хотите улучшить свои навыки разработки, вы должны начать думать с точки зрения асинхронных программ, управляемых событиями. Это не просто вопрос масштабируемости, это также ядро поддерживаемого программного обеспечения. Это также улучшит ваши навыки и даст вам прочную основу, чтобы стать лучшим программистом.

OMG Ponies · Accepted Answer · 2010-09-13T02-34-00.000Z

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

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

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

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