Подскажите по структуре базы данных

[SimbiX]

Подскажите по структуре базы данных

Подскажите пожалуйста по структуре базы данных. Нужно хранить информацию по фильмам.
К каждому фильму, относиться много информации.

а именно:

Название
Оригинальное название (анг)
Год
Страна
Слоган
Режиссер (в множестве)
Сценарий (в множестве)
Продюсер (в множестве)
Оператор (в множестве)
Композитор (в множестве)
Художник (в множестве)
Монтаж (в множестве)
Жанр (в множестве)
Бюджет
Сборы
Зрители
Примера
рейтинг MPAA
Продолжительность

таких фильмов будет много (порядка 50 000), и почти все однотипные, поэтому нужно как-то грамотно составить DB, что бы не было проблем в дальнейшем.

как я думал сделать:

Главная таблица в которую заносим

id - номер фильма
name - название
name_original - оригинальное название
type - тип картины (фильм, сериал)
year - год выпуска

здесь меня смущает нужно ли здесь держать (name, name_original) .. или вынести ее в отдельную таблицу


таблица с параметрами
film_id - номер фильма
property_id - номер название параметра
property_value - номер параметра


таблица с именами параметров
id - номер параметра
name - название параметра
code - код параметра для внутренних потребностей фронтенда


+ несколько таблиц справочников, для стран, жанров, etc

таблица для параметров что не входят в справочники
id - номер параметра
name - название параметра

вот здесь меня смущает что все параметры будут держаться в поле с типом varchar
а хорошо бы для
бюджет, сборы в США - interger,
премьера - date,
рейтинг MPAA - enum

разве что делать таблицу для параметров такой:

id - номер параметра
name_string - название параметра
name_integer - название параметра
name_datetime - название параметра
name_enum - название параметра

но хорошо ли так ??


+ еще не знаю как поступить с описаем фильмов, это TEXT, выносить ли в отдельную таблицу все описания, или запихать в таблицу параметров, что указана выше

Спасибо за уделенное внимание, и за будущие ответы

 

[Gas]

Не усложняй себе жизнь, храни все параметры фильмов, названия и описание в одной таблице. Режисёров, операторов, жанры, и т.д - таблицы справочники + таблицы связки M:M.
Таблицу с параметрами имеет смысл заводить только тогда, когда количество параметров over 9000 и/или они присутствуют у небольшого процента записей (и то, нужно думать, какие запросы по этим параметрам предстоят).

 

[prolis]

Сценарий (в множестве)
Продюсер (в множестве)
Оператор (в множестве)
Композитор (в множестве)
Художник (в множестве)

а тут можно схалтурить и хранить одной строкой

 

[Gas]

prolis
Неожиданный совет от тебя. Зачем одной строкой, а выборки как потом делать, лайком?

 

[SOKOJI]

prolis
Неожиданный совет от тебя. Зачем одной строкой, а выборки как потом делать, лайком?

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

Зависит еще от пользователей - не каждый при заполнении информации о фильме будет добавлять всю информацию подробно. Скорее всего, подобную строку (о сценарии, продюсере и т.д.) скопирует со стороннего сайта.

 

[Gas]

SOKOJI
сам часто иду на компромис в плане нормализации, но если я точно уверен что в обозримом будущем никаких операций над такими данными не предвидится и эти данные не зависят от пользовательского ввода. Что касается базы с фильмами, то поиск по актёрам,режисёрам будет, даже если ТС скажет что сейчас нет, то завтра всё равно такая необходимость понадобится + вопрос адекватности данных, а то Бред Питт, Бред Пит, Брэд Питт - это реальность. Самому сейчас досталась база с адресами, где адрес вводился одной строкой - улица "1-го Мая", фигурирует в 10 вариантах (там русский + украинский языки).
Вот от тебя, предложение хранить в одной строке, меня совершенно не удивляет (так как я просто не имею понятия о твоём уровне). Но от очень компетентного и опытного человека в области mysql - да, удивляет.

 

[Гамаюн]

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

 

[prolis]

Что касается базы с фильмами, то поиск по актёрам,режисёрам будет

Актеров и режиссеров никто сливать и не предлагал. Тут вопрос именно в возможности разумного компромисса. Цели создания базы нам не озвучили. Если для расчета себестоимости картины (а вдруг - то будем хранить все отдельно вплоть то года выдачи паспорта каждого участника. А если как описание фильмов в каталоге - то выделять в отдельные свойства необходимо и достаточно только поля, участвующие в поиске и сортировке

 

[predator]

Актеров и режиссеров никто сливать и не предлагал. Тут вопрос именно в возможности разумного компромисса. Цели создания базы нам не озвучили. Если для расчета себестоимости картины (а вдруг - то будем хранить все отдельно вплоть то года выдачи паспорта каждого участника. А если как описание фильмов в каталоге - то выделять в отдельные свойства необходимо и достаточно только поля, участвующие в поиске и сортировке

интересно а если вывод данных подразумевается не через запятую, то что - explode бум использовать? ))
В любом случае лучше всё хранить раздельно. Если функционал хранилища сделать одинаковым то компромисс ненужен.

Для параметров которые во множестве я бы сделал так: Хранил бы данные в разных таблицах, но с одинаковыми названиями полей (id, value). Класс который будет брать данные инициализировал именем таблицы. А имя таблицы хранилось бы в таблице с описанием параметров (также, описания параметров можно вынести из БД в поле класса, если не предполагается частое изменение этого списка). Дальше, если понадобится, делать какие-то усложнения в геттерах и сеттерах в зависимости от типа параметра. Выборка же данных будет работать по одной схеме для всех таблиц с параметрами. И общую таблицу линковки таблицы фильмов с таблицами справочниками (там film_id/param_id/flg_type).

Единичные параметры все хранил бы в одной общей таблице. 50 000 записей это не такое большое количество чтобы сильно переживать ) Тем более если такую таблицу грамотно проиндексировать, учитывая какие запросы к ней будут.