| Архив | Об архиве | FAQ | New BAN List | Полезные ссылки | Друзья архива | Архив новостей |
|
| Регистрация | Справка | Правила форума | Поиск | Сообщения за день | Пользователи | Календарь |
| Приёмная ArjLover-a Послания и пожелания по работе Архива |
 |
|
|
Опции темы | Опции просмотра |
31.03.2008, 18:57
|
|||
|
|||
|
Цитата:
 Надеюсь, рано или поздно пригодится.
|
|
31.03.2008, 21:18
|
|||
|
|||
|
Если бы я делал эту базу, она бы выглядела примерно так:
Код:
Таблица 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 // Комментарий Могу только сказать, что если базу плохо спроектировать (избыточность, отсутствие нормализации) можно потом всю жизнь её штопать кривыми скриптами и так и не добиться того, что при нормальной базе решается двумя строчками кода. На самом деле сложного здесь ничего нет. Самое кропотливое - написать клиентскую часть, т.е. формы для заполнения базы и для просмотра описаний. Но даже и с клиентской частью это довольно тривиальная работа. Тянет не больше, чем на курсовик или серию лабораторных работ.
|
|
31.03.2008, 22:25
|
|||
|
|||
|
Я тоже за то, чтобы пересмотреть решение в пользу раздельного хранения информации по таблицам.
1. Цитата:
2. Экономит место на повторяющейся информации. 3. Позволяет создать поиск по всевозможным критериям. 4. Упрощается совершенствование базы.
__________________
Помогу оцифровать интересные материалы для ArjLover (Рига, Латвия).
|
|
31.03.2008, 22:53
|
|||
|
|||
|
Цитата:
PS. В фильме "Три плюс два" стоит вырезать первые 20сек и последние минуты. Там идет непристойная реклама фильма "девочки сверху"...
|
|
31.03.2008, 23:00
|
|||
|
|||
|
Цитата:
Цитата:
Можно, конечно, и зайца научить курить... Но можно и пожалеть сервер (нагрузка при Вашем подходе вырастет на несколько порядков, что весьма критично для популярное интернет ресурса) и тех кто будет писать, изменять ПО этого сервера...
|
|
31.03.2008, 23:05
|
|||
|
|||
|
Цитата:
Неужели это может что-то изменить на фоне обычной нагрузки файловых серверов?
|
|
31.03.2008, 23:56
|
|||
|
|||
|
Цитата:
таблица 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;
|
|
01.04.2008, 00:08
|
|||
|
|||
|
Цитата:
- .... такой поиск на несколько порядков менее производителен, чем поиск по индексированным полям типа integer. +Кол-во единовременных коннектов на сервере - 3000. (взято с главной страницы).
|
|
01.04.2008, 00:09
|
||||
|
||||
|
Цитата:
 кончайте уже мучить базу... Нужен дизайн страницы... я что-то начинаю подумывать бросить это все и вернуть линки инфо на внешние источники
|
|
01.04.2008, 09:46
|
|||
|
|||
|
Цитата:
.Трудоёмкость создания базы что из одной таблицы, что из 17, занимает ничтожную долю процента от общего объёма работы. Ну нет, так нет. Практически к сожалению ничем помочь не могу 
|
|
01.04.2008, 12:44
|
|||
|
|||
|
Верхушка айсберга - это то, что видят пользователи. Административная часть, вот это огого.
Впрочем, если все же решите, делать по полному, могу попробовать помочь. Только сроки реальные дайте, и кто в дизайне помог бы. И на чем? Я, так с MySQL знаком.
__________________
Помогу оцифровать интересные материалы для ArjLover (Рига, Латвия).
|
|
01.04.2008, 12:54
|
|||
|
|||
|
Цитата:
Размер айсберга при однотабличной базе будет скорее всего больше. При одинаковом функционале все компромиссы, сделанные при проектировании базы, усложнят программирование.
|
|
01.04.2008, 13:06
|
|||
|
|||
|
Я тоже не пойму этой паники, почему, дескать, всё остановит простой общий текстовый поиск по целым словам с подстановками. У нас практически единственная модифицируемая часть — это добавление новых народных отзывов, а 5000 карточек всё равно сейчас вручную набивать, ну и вычитать их по-нормальному.
В нынешних кинобазах, несмотря на то, что они сделаны по правилам, косяков полно, и что-то никто не торопится их исправлять, годами...
|
|
01.04.2008, 13:35
|
||||
|
||||
|
Я пока только и слышу что общие слова.
Как сделать удобной набивку режиссеров и актеров и потом добавление их к каждому фильму? а если одного актера не оказалось в справочнике - надо идти добавлять его, потом опять возвращаться к фильму. и как это все будет выглядеть в html-интерфейсах? и к чему такая кропотливая работа? А я предлагаю просто сделать копи-паст всех актеров одним блоком с википедии в одно текстовое поле. Поиск по 5000 записям будет мгновенный в любом случае - это я вам обещаю. Узнать все фильмы режиссера? ну это не здесь!!! я не силен этим! Сходите на википедию. а я буду дальше бан-роботов писать.
|
|
01.04.2008, 14:27
|
|||
|
|||
|
Я так понимаю, что плоская модель базы данных была выбрана по следующим причинам:
+ Элементарный скрипт для добавления, модификации, удаления строки в таблице, требуются элементарные знания SQL. + Создатель базы не предполагает дополнять каждое поле в таблице какой-то информацией, т.е. информацию, указанную в полях, не предполагается расширять; если написали "В.Котёночкин", то так тому и быть отныне и вовеки веков. + Минимум времени затрачивается на создание базы и сопутствующих скриптов. При этом закрываются глаза на то, что: - Удобство пользователей базы не берётся в расчёт, только "сложность" телодвижений для реализации базы. - Каждое текстовое поле нужно будет забивать вручную каждый раз (тысячи раз набивать одно и то же), при этом количество мелких ошибок, связанных с ручным вводом слова, будет велико и отлавливать их будет сложно и долго. - Низкая скорость добавления строки в таблицу и обновления данных, много тупого ручного труда. - Плоская база будет весить в памяти больше, чем реляционная. - Выборки по текстовым полям нааамного дольше выполняются, чем по индексируемым числовым полям и являются некорректными, если база содержит ошибочные данные в полях. - Дублируемость текстовой информации. - Невозможность изменить полноту информации, представленную в каждом поле. - Очень сложно из такой базы сделать выборку по интересующей информации: как найти мультик с нужным мне "актёром". - У одного мультика бывает 1 режиссёр/композитор/сценарист, а ведь бывает и несколько. Что - через зяпятую писать? А искать потом как по этому полю? - Поля "type" и "genre" мне вообще не ясны - в каждом поле одна строка или несколько через запятую? Если мультик характеризуется хотя бы так: детский, рисованый, музыкальный, то что тут "тип", а что "жанр"? ------------- То есть, по сути, получается обычная таблица в Excel, которую пишет любой юзер, когда хочет описать то, что имеется на дисках. ------------- На мой взгляд, подход нерациональный, даже если учесть "статичность" информации, которую нужно систематизировать. Извиняюсь за критику, но: Делать "абы как", а смысл? Ещё одна недоделанная, неполная, неудобная база, коих полно в интернете? Есть хорошее выражение, характеризующее такой подход - "тяп-ляп". Зачем нужна тогда тут база вообще? Если чтобы найти нужные видеоматериалы, по-прежнему придётся пользоваться сторонними ресурсами, а тут только качать. В таком случае самое удобное - это сделать как раньше (ещё меньше телодвижений) и на страничке со списком видеофайлов оставить только ссылки на описание, на тот же аниматор или википедию, и ссылки "Скачать", остальное либо лишнее, либо надо делать как следует...
__________________
Feci qoud potui, faciant meliora potentes. Последний раз редактировалось Digrol, 01.04.2008 в 14:35.
|
Прага
Рига
Линейный вид
