Подскажите пожалуйста по структуре базы данных. Нужно хранить информацию по фильмам.
К каждому фильму, относиться много информации.
а именно:
Название
Оригинальное название (анг)
Год
Страна
Слоган
Режиссер в множестве
Сценарий (в множестве)
Продюсер (в множестве)
Оператор (в множестве)
Композитор (в множестве)
Художник (в множестве)
Монтаж (в множестве)
Жанр (в множестве)
Бюджет
Сборы
Зрители
Примера
рейтинг MPAA
Продолжительность
таких фильмов будет много (порядка 80 000), и почти все однотипные, поэтому нужно как-то грамотно составить DB, что бы не было проблем в дальнейшем.
как я думал сделать:
Главная таблица (catalog) в которую заносим
id — номер фильма
name — название
name_original — оригинальное название
type — тип картины (фильм, сериал)
year — год выпуска
здесь меня смущает нужно ли здесь держать (name, name_original)… или вынести ее в отдельную таблицу
таблица с параметрами (catalog_properties)
film_id — номер фильма
property_id — номер название параметра
property_value — номер параметра
таблица с именами параметров (catalog_properties_name)
id — номер параметра
name — название параметра
code — код параметра для внутренних потребностей фронтенда
+ несколько таблиц справочников, для стран, жанров, etc
таблица для параметров что не входят в справочники (catalog_properties_data)
id — номер параметра
name — название параметра
вот здесь меня смущает что все параметры будут держаться в поле с типом varchar
а хорошо бы для
бюджет, сборы в США — interger,
премьера — date,
рейтинг MPAA — enum
разве что делать таблицу для параметров такой:
id — номер параметра
name_string — название параметра
name_integer — название параметра
name_datetime — название параметра
name_enum — название параметра
и выбирать в дальнейшем так "SELECT CONCAT_WS('', name_string, name_integer, name_datetime, name_enum) as name" но хорошо ли так ??
+ еще не знаю как поступить с описанием фильмов, это будет тип TEXT, выносить ли в отдельную таблицу все описания, или запихать в таблицу параметров, что указана выше
1.
> здесь меня смущает нужно ли здесь держать (name, name_original)… или вынести ее в отдельную таблицу
Все что можно не выносить из основной таблицы — лучше там оставить.
У вас написано, что name_original — на английском, значит не надо выносить.
Получаются все фильмы англоязычные?
2.
Первым делом определитесь, какие значения могут принимать все параметры, например:
Слоган # на английском, на русском?
Сборы # сборы по странам или всего в мире?
Зрители # нужно ли количество зрителей по странам или всего в мире?
Примера # по странам? в США? мировая?
Если только одно значение и других не подразумевается, то храните его в основной таблице.
3.
таблица для параметров что не входят в справочники
что это за параметры?
> здесь меня смущает нужно ли здесь держать (name, name_original)… или вынести ее в отдельную таблицу
безусловно, лучше хранить в этой же таблице
> и выбирать в дальнейшем так «SELECT CONCAT_WS('', name_string, name_integer, name_datetime, name_enum) as name» но хорошо ли так ??
лично я не стал бы усложнять, пусть лучше будет varchar, 80к записей не так ж и много, но если все-таки хотите разделить то думаю будет правильней создать 3 таблицы для каждого нужного типа т.е. catalog_properties_data_string, catalog_properties_data_int, catalog_properties_data_datetime и соответственно добавить поле type в таблицу catalog_properties
да 80 тысяч это совсем немного…
Если база проектируется с учетом поиска, то рекомендую в последствии использовать сфинкс, который создает свой собственный индекс и при запросе практически всё равно какая структура бд.
Не надо так разделять. 80к — это копейки. Но:
1. обязательно настройте индексы.
2. если в 90% случаев нужно только название + режисёр, то не надо писать SELECT *… Перечислите все нужные поля.
На крайний случай, можете разделить одну таблицу на две со связью один-к-одному. В первой должны быть те поля которые используются всегда (id, название, режисёр), во второй все остальные. Это позволит писать SELECT * FROM `t1`.
Простой
Простой
