Python-сообщество

Мне нужно хранить:
1) Даты премьер фильмов (мировая, в США, России и Украине - это по минимуму)
2) Даты сеансов
3) Время сеансов

Задача:
1) Выводить даты премьер как статическую информацию отдельной строкой + делать выборку (фильтр во фронт-енде) фильмов по датам премьер (по неделям, по месяцам, годам).
2) Выводить даты сеансов как статику + делать выборку (фильтр во фронт-енде).
3) Выводить время сеансов как статику + делать выборку (фильтр во фронт-енде)
4) Выводить в названии, или отдельной строкой + делать выборку (фильтр во фронт-енде) фильмов по годам производства (class Movie -> production_year).

На данный момент, после правок полей, модель выглядит в сокращенном виде так:

class Country(models.Model):
   name
   short_name
class Profit(models.Model):
    weeks
    weekend_profit
    weekend_ppl
    total_profit
    total_ppl
    premier_date
    movie = models.ForeignKey(Movie)    
    country = models.ForeignKey(Country, null=True)    # null == world
#############################################
class Cinema(models.Model):
    movie = models.ManyToManyField(Movie, through='MoviesTimetable')    
    city
    name
    street
    phone
class Movie(models.Model):
    # новое поле
    production_year
    name
    length
    genre
    description
class MoviesTimetable(models.Model):
    movie = models.ForeignKey(Movie)
    cinema = models.ForeignKey(Cinemas)
    dates
    times

Отредактировано TitanFighter (Сен. 24, 2015 17:36:59)

Для расписания схема, думаю, примерно такая

Все ключи намеренно искусственные. Таблица Show правда довольно хорошо расти будет - пять-шесть сеансов в день, это на один кинотеатр в год ~2000, на сто кинотеатров ~200000 записей в год. Если не устраивает, то как вариант, можно что-то такое

но все становится сильно замороченнее(хотя если сделать естественные первичные ключи, то выглядит чуть приятней) так что я бы остановился на первом варианте.

Раскройте подробнее про даты премьер, внесем и их, далее у вас какой то profit появился, сборы что ли? Вы про них не говорили

По поводу Profit - это кассовые сборы, вы верно догадались. Я и сам не знал, что они будут) Первую версию сайта я сделал еще в средине августа, когда вы мне подсказали с полями. Сейчас уже делаю 2ую версию.

По датам премьер все просто - в разных странах разные даты начала показов.
По кассовым сборам аналогично - в разных странах разные сборы и разное к-во посетителей.
Поле weeks из класса Profit думаю исключить и высчитывать исходя из даты премьеры (вроде так гласит правило нормализации - не нужно хранить то, что можно высчитать используя другие данные).

Я думал, куда премьеры включить, или в Show или в Profit (кассовые сборы). Решил в сборы, потому как премьеры зависят от стран, и сами кассовые сборы тоже зависят от стран.

Касательно к-ва сеансов в 1 день в 1 кинотеатре и нагрузки на БД (200 000 сеансов в год при 5-6 сеансах для 100 кинотеатров)…

Только что открыл один кинотеатр - 50 сеансов в день)
В России + Украине кинотеатров 300-400, пускай в среднем по 25 сеансов в каждом. В итоге 7 500-10 000 сеансов в день. За год 2,74 млн - 3,65 млн.
Для баз данных “много” и “тяжело” с каких цифр начинается 100 тыс, 1 млн, 10 млн?)

По поводу вынесения в отдельные таблицы всего чего только можно, вроде наконец разобрался. Вроде теперь понял, что такое нормализация, и понял, что с временем и датой переборщил и не нужно их никуда выносить.

Отредактировано TitanFighter (Сен. 25, 2015 22:40:33)

Смотрите : премьеры в разных станах в разное время - выносите их в отдельную таблицу ( movie fk, country fk. date ). Аналогично с кассовыми сборами.

С премьерами и кассовыми сборами понятно. Спасибо.
Подскажите по поводу Сеансов - не могу въехать.
PooH предлагает в Сеансах Date и Time заменить на DateTime.
Я таблицы никогда с нуля не строил, так как не было необходимости. Я только с ними работал на достаточно простом уровне.
Правильно ли я понимаю, что фильтрация по дате и\или по времени в данном случае (DateTime) будет занимать дольше времени и нагружать сильнее базу?
Просто я тут погуглил (1, 2), как правильно из DateTime вытягивать отдельно дату и отдельно время… Есть мнение, что лучше сделать 2 поля Date и Time, чем одно DateTime, по причине большой нагрузки на базу в последнем случае.