Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подскажите по структуре базы данных / 9 сообщений из 9, страница 1 из 1
31.01.2011, 19:45
    #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
| Ответить | Цитировать | Написать  
01.02.2011, 08:47
    #37089734
Программист-Любитель
Программист-Любитель
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите по структуре базы данных
Вы на пути изобретения EAV. Если хотите, можно легко нагуглить готовые паттерны.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.02.2011, 11:17
    #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:26
    #37090089
Chop
Chop
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите по структуре базы данных
Chop...
вдогонку...
для Справочников Страны , Типы , Жанры можно изначально реализовать не связь один-ко-многим , как я написал, а многие-ко-многим - может оказаться востребованным.
Для этого достаточно убрать соответствующий внешний ключ в справочнике Фильмы и добавить таблицу связи, например:
Таблица связи Фильмы-Страны:
Код: plaintext
1.
1.     КодФильмы
2.     КодСтраны
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.02.2011, 12:36
    #37090356
kink
kink
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Подскажите по структуре базы данных
Simbix,

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

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

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

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


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