ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите по структуре базы данных
9 сообщений из 9, страница 1 из 1
Подскажите по структуре базы данных
    #37089199
Simbix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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 , выносить ли в отдельную таблицу все описания, или запихать в таблицу параметров, что указана выше

Спасибо за уделенное внимание, и за будущие ответы :)
...
Рейтинг: 0 / 0
31.01.2011, 19:45
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37089734
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Программист-Любитель
Участник
Вы на пути изобретения EAV. Если хотите, можно легко нагуглить готовые паттерны.
...
Рейтинг: 0 / 0
01.02.2011, 08:47
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37090059
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Chop
Участник
Справочник Фильмы:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
1.	Код
2.	НаименованиеРус
3.	НаименованиеОригинальное
4.	КодСтраны
5.	Слоган
6.	Бюджет
7.	Сборы
8.	Зрители
9.	Продолжительность
10.	КодТипа
11.	КодЖанра
12.	итд

Справочник Роли:
Код: plaintext
1.
1.	Код
2.	Наименование

Код: plaintext
1.
 Примерный перечень:
Режиссер

Сценарист

Продюсер

Оператор

Композитор

Художник

Актер

СекретуткаРежиссера

итд

Справочник Люди:
Код: plaintext
1.
1.	Код
2.	Наименование

Таблица связи Фильмы-Роли-Люди:
Код: plaintext
1.
2.
1.	КодФильмы
2.	КодРоли
3.	КодЛюди

Справочник Страны
Код: plaintext
1.
1.	Код
2.	Наименование

Справочник Типы
Код: plaintext
1.
1.	Код
2.	Наименование

Справочник Жанры
Код: plaintext
1.
1.	Код
2.	Наименование

Таблицами параметров лучше не заморачиваться – при кажущемся упрощении схемы БД чревато дополнительными геморроями.

Задолбаешся через полгода разбираться куда какой и зачем параметр.

Существенно проще и поддерживать и развивать систему.
Представь, что через некоторое время возникнет потребность в справочнике Люди указывать страну.
Что будешь делать с одной таблицей? – Так или иначе придется добавлять какую-то дополнительную таблицу…
Почему не сделать этого сразу?

При впихивании всех параметров в одну таблицу – скорее всего никуда та не денешься – придется в коде прописывать айдишники записей…
Поменяются коды – слетит вся твоя система.
Итд итп.

Т.е. пусть лучше будут однотипные справочники Люди, Страны, Жанры, Типы итд, чем один справочник Параметры.
Они однотипные только в самом начале, при развитии системы Код и Наименование могут оказаться единственными полями по которым они будут совпадать.
...
Рейтинг: 0 / 0
01.02.2011, 11:17
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37090089
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Chop
Участник
Chop...
вдогонку...
для Справочников Страны , Типы , Жанры можно изначально реализовать не связь один-ко-многим , как я написал, а многие-ко-многим - может оказаться востребованным.
Для этого достаточно убрать соответствующий внешний ключ в справочнике Фильмы и добавить таблицу связи, например:
Таблица связи Фильмы-Страны:
Код: plaintext
1.
1.     КодФильмы
2.     КодСтраны
...
Рейтинг: 0 / 0
01.02.2011, 11:26
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37090356
kink
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kink
Гость
Simbix,

EAV который вы изобретаете конечно крут, но для вышей задачи он не требуется (если конечно не любишь микроскопом орехи колоть).
Chop подробно расписал как СТОИТ реализовать.
...
Рейтинг: 0 / 0
01.02.2011, 12:36
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37090873
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Chop
Участник
kinkEAV ... конечно крут, но...
ИМХО, согласен с мнением
авторИспользовать паттерн EAV возможно только в качестве дополнения к более разумным подходам,
если всё-таки нужно предусмотреть динамическое добавление 1-2 полей к существующим сущностям.
Но ни в коем случае не 10 и не 50 полей.
EAV - это выворачивание реляционной модели наизнанку.

Слишком сложная система получится.
тынц

в практике пришлось использовать всего один раз, иначе было никак
через полгода уже не въедешь, что там и как, хотя и документировать пытался по максимуму
...
Рейтинг: 0 / 0
01.02.2011, 14:52
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37091391
Simbix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Simbix
Гость
Спасибо за ответы. Меня вот еще интересует быстродействие предложенной Вами схемы (плюс нужно предусмотреть возможность масштабирования) + почти по каждому параметру должна быть возможность поиска:
Название
Оригинальное название (анг)
Год
Страна
Слоган
Режиссер (в множестве)
Сценарий (в множестве)
Продюсер (в множестве)
Оператор (в множестве)
Композитор (в множестве)
Художник (в множестве)
Монтаж (в множестве)
Жанр (в множестве)
Бюджет
Сборы
Зрители
Примера
рейтинг MPAA
Продолжительность
...
Рейтинг: 0 / 0
01.02.2011, 17:19
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37091587
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Chop
Участник
SimbixМеня вот еще интересует быстродействие предложенной Вами схемы (плюс нужно предусмотреть возможность масштабирования) + почти по каждому параметру должна быть возможность поиска:
1. при 50 000 тыс записей вопросами быстродействия можно не заморачиваться
2. масштабируется что? кол-во полей/таблиц или кол-во записей?
3. поиск делается элементарно

зы.
схема - одна из стандартных (и самых простых) реляционных
методик по ней море
вопросы быстродействия зависят от очень многих параметров конкретной системы и являются темой для холивара
...
Рейтинг: 0 / 0
01.02.2011, 18:19
| Ответить | Цитировать | Написать  
Подскажите по структуре базы данных
    #37091594
Фотография Chop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Chop
Участник
Chop1. при 50 000 тыс записей вопросами быстродействия можно не заморачиваться
забыл добавить - и вменяемом количестве одновременных пользователей
:)
...
Рейтинг: 0 / 0
01.02.2011, 18:21
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите по структуре базы данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=37091391&tid=1542335]:
 0ms
get settings:
 11ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 358ms
get topic data:
 17ms
get forum data:
 4ms
get page messages:
 64ms
get tp. blocked users:
 2ms
others: 240ms
total:  720ms
созд. / загр.: 720ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]