Архив | Об архиве | FAQ | New BAN List | Полезные ссылки | Друзья архива | Архив новостей |
|
Регистрация | Справка | Правила форума | Поиск | Сообщения за день | Пользователи | Календарь |
Приёмная ArjLover-a Послания и пожелания по работе Архива |
|
Опции темы | Опции просмотра |
|
|||
Почему бы и нет Надеюсь, рано или поздно пригодится.
|
|
|||
Если бы я делал эту базу, она бы выглядела примерно так:
Код:
Таблица 1 - Фильмы number int(4) // Номер фильма <первичный ключ> origin_title varchar(250) // Оригинальное название title varchar(250) // Русское название year int(4) // Год subtitle varchar(250) // Путь к файлу субтитров writer varchar (250) // Сценарий - Не очень понимаю чем отличается сюжет от сценария :) tagline text // Сюжет // Я бы вместо этого просто оставил поле: description text // Описание // Дальше тут идёт внутренняя кухня архива, которую я не знаю - параметры файла, // ссылки на скриншоты, md5 и т.д. //--------------------------------------------------------- Таблица 2 - Творцы :) number int(4) // Номер творца <первичный ключ> orig_name varchar(250) // Оригинальное ФИО name varchar(250) // Русское ФИО // Это нужно для более простой визуальной идентификации тёзок при вводе. // Указание годов жизни сведёт число коллизий к минимуму. b_year int(4) // Год рождения d_year int(4) // Год смерти // Здесь можно добавить какое-то текстовые поля, типа краткой биографии, // можно связать эту таблицу со странами, и т.д. // Но для архива всё это избыточно. //--------------------------------------------------------- // Дальше идут мелкие таблицы - жанры, тэги, страны и тп. // Они выделяются в отдельные таблица для того, что бы проще было // делать выпадающие списки в формах заполнения описаний и тп. // Отдельные таблицы гарантируют отсутствие опечаток. // Если это может быть сделано путём индексации текстового поля // в фильмах, или просто не нужно, можно вместо них оставить обычные тестовые // поля в фильмах. //--------------------------------------------------------- Таблица 3 - Страны country varchar (100) // Страна (общепринятая русская транскрипция) <первичный ключ> Таблица 4 - Студии origin_name varchar (100) // Оригинальное название <первичный ключ> name varchar (100) // Русское название Таблица 5 - Жанры genre varchar (100) // Жанр <первичный ключ> // Под "типом мультика" насколько я понял подразумевались какие-то мелкие поджанры, тэги. // Типа как на imdb "о двух напарниках", "про утят", "в конце все умирают" и т.п. :) Таблица 6 - Тэги type varchar (100) // Тэг (тип) <первичный ключ> //--------------------------------------------------------- // Дальше идут стандартные таблицы, разрешающие отношения многие-ко многим //--------------------------------------------------------- Таблица 7 - Фильмы - Режиссёры movie int(4) // Фильм - номер из Таблицы 1 | director int(4) // Режиссёр - номер из Таблицы 2 | <Первичный ключ - пара Фильм-Режиссёр> Таблица 8 - Фильмы - Сценаристы movie int(4) // Фильм - номер из Таблицы 1 | writer int(4) // Сценарист - номер из Таблицы 2 | <Первичный ключ - пара Фильм-Сценарист> Таблица 9 - Фильмы - Операторы movie int(4) // Фильм - номер из Таблицы 1 | operator int(4) // Оператор - номер из Таблицы 2 | <Первичный ключ - пара Фильм-Оператор> Таблица 10 - Фильмы - Композиторы movie int(4) // Фильм - номер из Таблицы 1 | composer int(4) // Композитор - номер из Таблицы 2 | <Первичный ключ - пара Фильм-Композитор> Таблица 11 - Фильмы - Художники movie int(4) // Фильм - номер из Таблицы 1 | artist int(4) // Художник - номер из Таблицы 2 | <Первичный ключ - пара Фильм-Художник> Таблица 12 - Фильмы - Актёры movie int(4) // Фильм - номер из Таблицы 1 | actor int(4) // Актёр- номер из Таблицы 2 | <Первичный ключ - пара Фильм-Актёр> // Если жалко дублировать строку, таблицы стран, жанров и тп. тоже можно пронумеровать. Таблица 13 - Фильмы - Страны movie int(4) // Фильм - номер из Таблицы 1 | country varchar (100) // Страна - ключ из Таблицы 3 | <Первичный ключ - пара Фильм-Страна> Таблица 15 - Фильмы - Студии movie int(4) // Фильм - номер из Таблицы 1 | origin_name varchar (100) // Студия - ключ из Таблицы 4 | <Первичный ключ - пара Фильм-Студия> Таблица 16 - Фильмы - Жанры movie int(4) // Фильм - номер из Таблицы 1 | genre varchar (100) // Жанр - ключ из Таблицы 5 | <Первичный ключ - пара Фильм-Жанр> Таблица 17 - Фильмы - Тэги movie int(4) // Фильм - номер из Таблицы 1 | type varchar (100) // Тэг - ключ из Таблицы 6 | <Первичный ключ - пара Фильм-Тэг> //--------------------------------------------------------- // И последняя - самая важная таблица :) //--------------------------------------------------------- Таблица 18 - Комментарии movie int(4) // Фильм - номер из Таблицы 1 comment text // Комментарий Могу только сказать, что если базу плохо спроектировать (избыточность, отсутствие нормализации) можно потом всю жизнь её штопать кривыми скриптами и так и не добиться того, что при нормальной базе решается двумя строчками кода. На самом деле сложного здесь ничего нет. Самое кропотливое - написать клиентскую часть, т.е. формы для заполнения базы и для просмотра описаний. Но даже и с клиентской частью это довольно тривиальная работа. Тянет не больше, чем на курсовик или серию лабораторных работ. |
|
|||
Я тоже за то, чтобы пересмотреть решение в пользу раздельного хранения информации по таблицам.
1. А также упрощяют их исправление. 2. Экономит место на повторяющейся информации. 3. Позволяет создать поиск по всевозможным критериям. 4. Упрощается совершенствование базы.
__________________
Помогу оцифровать интересные материалы для ArjLover (Рига, Латвия). |
|
|||
Цитата:
PS. В фильме "Три плюс два" стоит вырезать первые 20сек и последние минуты. Там идет непристойная реклама фильма "девочки сверху"... |
|
|||
Цитата:
Цитата:
Можно, конечно, и зайца научить курить... Но можно и пожалеть сервер (нагрузка при Вашем подходе вырастет на несколько порядков, что весьма критично для популярное интернет ресурса) и тех кто будет писать, изменять ПО этого сервера... |
|
|||
Цитата:
Неужели это может что-то изменить на фоне обычной нагрузки файловых серверов? |
|
|||
Цитата:
таблица film id int4 primary key film varchar(128) // название f_size int4 // file_size f_video_info varchar// e.g. 640x480 25fps DivX5 1.2Mbps f_audio_info varchar// e.g. 48KHz Stereo 192Kbps mp3 f_length int // длительность (секунды) bukva char(1) // для облегчения запроса вывода фильмов на букву "А" path varchar // путь к файлу year int2 story text // сюжет href1 varchar//ссылка1 на внеш. ресурс href2 varchar//ссылка2 на внеш. ресурс href3 varchar//ссылка3 на внеш. ресурс date1 // дата создания записи date2 //дата последнего редактирования note text//служеб.примеч. ========= табл. person_type id int2 primary key ptype varchar(64)// e.g. актер, композитор, режиссер ========== табл. person id int4 primary key fio varchar// ФИО; врядли потребуется разбивать ФИО на Ф. И. и О., но ..? bio text href1 varchar//ссылка1 на внеш. ресурс href2 varchar//ссылка2 на внеш. ресурс href3 varchar//ссылка3 на внеш. ресурс note text// служ.примеч. ========== табл. genre id genre_name ===== ....и т.п. ===== ТАБЛИЦЫ связки: табл. film_person f_id int // film.id вторич.ключ+тригер p_id int // person.id -"- ptype_id int// person_type.id -"- p_weight int2 default 30// "вес" данной персоны для данного фильма: Это поле необходимо для нормального вывода персон к конкрет. фильму, т.е. напр. сначала гл. актеры, потом второстепенные используя различные значения в этом поле и сортировку по этому полю в запросе, можно получить правильную последовательность выводимых персон. Напр. вывод актеров (ptype.ID=2) из фильма с ID=7: (запрос не проверял, может и неправильный, но суть там в ORDER BY) select p.fio,f_p.weight from person p, person_type pt,film f, f_p where f_p.f_id = 7 AND f.id = 7 AND f_p.p_id=p.id AND pt.id = 2 order by f_p.weight; |
|
|||
Цитата:
- .... такой поиск на несколько порядков менее производителен, чем поиск по индексированным полям типа integer. +Кол-во единовременных коннектов на сервере - 3000. (взято с главной страницы). |
|
|||
на самом деле напрасно. Честное слово, это дело на 30 мин для любого студента .
Трудоёмкость создания базы что из одной таблицы, что из 17, занимает ничтожную долю процента от общего объёма работы. Ну нет, так нет. Практически к сожалению ничем помочь не могу |
|
|||
Верхушка айсберга - это то, что видят пользователи. Административная часть, вот это огого.
Впрочем, если все же решите, делать по полному, могу попробовать помочь. Только сроки реальные дайте, и кто в дизайне помог бы. И на чем? Я, так с MySQL знаком.
__________________
Помогу оцифровать интересные материалы для ArjLover (Рига, Латвия). |
|
|||
немного не так.
Размер айсберга при однотабличной базе будет скорее всего больше. При одинаковом функционале все компромиссы, сделанные при проектировании базы, усложнят программирование. |
|
|||
Я тоже не пойму этой паники, почему, дескать, всё остановит простой общий текстовый поиск по целым словам с подстановками. У нас практически единственная модифицируемая часть — это добавление новых народных отзывов, а 5000 карточек всё равно сейчас вручную набивать, ну и вычитать их по-нормальному.
В нынешних кинобазах, несмотря на то, что они сделаны по правилам, косяков полно, и что-то никто не торопится их исправлять, годами... |
|
|||
Я так понимаю, что плоская модель базы данных была выбрана по следующим причинам:
+ Элементарный скрипт для добавления, модификации, удаления строки в таблице, требуются элементарные знания SQL. + Создатель базы не предполагает дополнять каждое поле в таблице какой-то информацией, т.е. информацию, указанную в полях, не предполагается расширять; если написали "В.Котёночкин", то так тому и быть отныне и вовеки веков. + Минимум времени затрачивается на создание базы и сопутствующих скриптов. При этом закрываются глаза на то, что: - Удобство пользователей базы не берётся в расчёт, только "сложность" телодвижений для реализации базы. - Каждое текстовое поле нужно будет забивать вручную каждый раз (тысячи раз набивать одно и то же), при этом количество мелких ошибок, связанных с ручным вводом слова, будет велико и отлавливать их будет сложно и долго. - Низкая скорость добавления строки в таблицу и обновления данных, много тупого ручного труда. - Плоская база будет весить в памяти больше, чем реляционная. - Выборки по текстовым полям нааамного дольше выполняются, чем по индексируемым числовым полям и являются некорректными, если база содержит ошибочные данные в полях. - Дублируемость текстовой информации. - Невозможность изменить полноту информации, представленную в каждом поле. - Очень сложно из такой базы сделать выборку по интересующей информации: как найти мультик с нужным мне "актёром". - У одного мультика бывает 1 режиссёр/композитор/сценарист, а ведь бывает и несколько. Что - через зяпятую писать? А искать потом как по этому полю? - Поля "type" и "genre" мне вообще не ясны - в каждом поле одна строка или несколько через запятую? Если мультик характеризуется хотя бы так: детский, рисованый, музыкальный, то что тут "тип", а что "жанр"? ------------- То есть, по сути, получается обычная таблица в Excel, которую пишет любой юзер, когда хочет описать то, что имеется на дисках. ------------- На мой взгляд, подход нерациональный, даже если учесть "статичность" информации, которую нужно систематизировать. Извиняюсь за критику, но: Делать "абы как", а смысл? Ещё одна недоделанная, неполная, неудобная база, коих полно в интернете? Есть хорошее выражение, характеризующее такой подход - "тяп-ляп". Зачем нужна тогда тут база вообще? Если чтобы найти нужные видеоматериалы, по-прежнему придётся пользоваться сторонними ресурсами, а тут только качать. В таком случае самое удобное - это сделать как раньше (ещё меньше телодвижений) и на страничке со списком видеофайлов оставить только ссылки на описание, на тот же аниматор или википедию, и ссылки "Скачать", остальное либо лишнее, либо надо делать как следует...
__________________
Feci qoud potui, faciant meliora potentes. Последний раз редактировалось Digrol, 01.04.2008 в 14:35. |