Архив | Об архиве | FAQ | New BAN List | Полезные ссылки | Друзья архива | Архив новостей |
|
Регистрация | Справка | Правила форума | Поиск | Сообщения за день | Пользователи | Календарь |
Приёмная ArjLover-a Послания и пожелания по работе Архива |
|
Опции темы | Опции просмотра |
|
|||
Digrol, вроде всё это уже обсудили.
Заполнять плоскую базу проще, нужна намного меньшая концентрация внимания да и просто быстрее это. Издержки дублирования и поиска несущественны. По неструктурированным текстовым полям (актёры, режиссёры) - полнотекстовый поиск. Я знаю пример кинобазы сделанной именно так и именно для облегчения труда админов. Баз работает много лет и всё не так уж страшно. Как аннотации к файлам её хватает. Но и не более того. Последний раз редактировалось troll, 01.04.2008 в 14:43. |
|
|||
Я так понимаю, что ArjLover тогда уж сперва хочет услышать, какой интерфейс предлагают сторонники нормальной базы. Если при заполненнии карточки нужно будет выбирать актёров, режиссёров, и прочих элементов, из бесконечных выкидных меню, то на такое никто не согласится, естественно.
Ну например, возможен ли хотя бы такой вариант интерфейса — при вставке готовой строки, содержащей перечисление актёров, они все тут же искались с допусками в базе, и совпавшие помечались бы одним цветом, частично совпавшие другим, и отсутствующие третьим. При этом контекст у совпавших должен быть в виде фрагмента алфавитного списка с пометкой данной позиции, у частично — в виде набора попавших вариантов из того же списка, у отсутствующих — в виде фрагмента алфавитного списка с указанием предлагаемого места их вставки. |
|
|||
Я про то и говорю, зачем изобретать велосипед и делать так же или хуже, чем уже сделано?
Для аннотации - ссылка на внешний источник, сделанный ранее, ну для поиска, собственно, тоже внешние источники использовать, т.к. эта база не предназначена для поиска. Вот простой вопрос - зачем нужна такая база? Для каких целей её будет удобно использовать?
__________________
Feci qoud potui, faciant meliora potentes. Последний раз редактировалось Digrol, 01.04.2008 в 15:33. |
|
|||
Цитата:
И в любом случае это требует дополнительного времени и внимания при заполнении. Цитата:
- Что бы иметь возможность ввести описание того, что на внешних сайтах отсутствует или описано одной строчкой. - Да и просто удобно видеть описание вместе с параметрами файла, скриншотами и прочим. |
|
||||
Так, я окончательно запуталась в чужих речах . То говорят про полнотекстовый поиск, то про то, что нельзя будет искать фильмы по режиссеру. Объясните простыми словами, можно будет найти все фильмы 63-го года или все фильмы с Никулиным, или нет?
|
|
|||
Я не согласен с konst5 в том, что полнотекстовый индекс (FULLTEXT) в MySQL по 5000 записей будет работать медленно. Я использовал его на базе в миллион записей, поисковые запросы обрабатывались за доли секунды. Индекс там строится так же, как Яндекс или Google индексируют веб-сайты: разбивает все строки на отдельные слова, поисковый запрос разбивает тоже на слова и ищет в индексе по каждому слову отдельно, затем соединяет результаты.
Но в целом согласен, что несколькими таблицами можно сделать более универсальную базу, которую в будущем можно крутить как угодно, и избежать разных обозначений одинаковых объектов уже на этапе ввода информации. Поэтому можно взять за основу БД вариант, предложенный konst5, если удастся хорошо автоматизировать процесс заполнения такой базы. Варианты автоматизации: 1. При вводе любого поля срабатывает подсказка из ближайших значений, имеющихся в базе. Принцип тот же, как Google уже на этапе ввода запроса подсказывает другие популярные запросы, начинающиеся с введённых букв или слов. Скриптик можно вытащить прямо из кода главной страницы Google. 2. Текстовое поле, куда можно: - скопировать любой текст - указать разделитель между объектами - выбрать, какие объекты перечислены в этом тексте (актёры, жанры и т.п.) - нажать одну кнопку и получить формочку с заполненными полями по данным из этого текста. Несовпадения с имеющимися значениями в базе сразу отмечаются. Там же можно быстро выбрать правильные значения из списка ближайших. 3. Для самых крупных сайтов, с которых будут браться данные по сотням фильмов/мультиков, написать парсеры веб-страничек. При заполнении базы человек вводит только ссылку на описание фильма, которое нужно разобрать - далее скрипт автоматически заполняет все поля, которые смог оттуда вытащить, предлагая человеку только подправить расхождения с имеющимися значениями (как в предыдущем пункте). Пункты 1,2 делаются довольно просто средствами HTML и JavaScript. Для написания парсеров веб-страниц можно подключить добровольцев с форума. Последний раз редактировалось AlexeyPetrov, 02.04.2008 в 12:39. |
|
|||
Цитата:
Цитата:
Что касается моей схемы БД. То там следует сделать важное уточнение: следует разнести данные о фильме как о таковом, и данные об файлах (.avi), т.к. есть многосерийные фильмы... |
|
|||
Цитата:
Обработал 50 фильмов за 15 сек. Результат - в текстовых файлах. Могу поделиться . Скажите куда архивчик скинуть... Нашел как прикрепить файлик... Кодировка - koi8-r В архиве Каталог FILMS/, где есть README (описание краткое) Последний раз редактировалось konst5, 02.04.2008 в 03:48. Причина: добавил файл |
|
|||
konst5, полезно будет выложить и сам скрипт, которым ты странички с nashekino разбирал.
Кстати, поиск с использованием полнотекстового индекса в MySQL делается не через LIKE, а функцией MATCH. Подробности тут: http://www.mysql.ru/docs/man/Fulltext_Search.html Последний раз редактировалось AlexeyPetrov, 02.04.2008 в 13:17. |
|
|||
Предалагаю для примера посмотреть большую коллекцию фильмов.
Структуру каталога и описаний. http://media.academ.info/media_page.php?section=video Все пользователи очень хвалят удобство. В отличии, скажем, вот от такого: http://www.cn.ru/films/ Первый портал буквально с этого месяца перевёл отдачу ресурсов через p2p, до этого было http|smb|ftp |
|
|||
Цитата:
|
|
|||
Цитата:
Последний раз редактировалось AlexeyPetrov, 02.04.2008 в 13:20. |
|
|||
Цитата:
Желательно было бы получить отзывы о том, что я вывел... Какие поля еще следует добавить?... Как лучше расположить для дальнейшей обработки? Я, напр., уже заметил, что забыл включить поле SIZE_of_file, хотя в скрипте он заложен. А также попробую выудить ГОД ВЫПУСКА из наше_кино... Потом напущу скрипт на на все фильмы из листинга - и рез-т выложу (правда здесь есть ограничения на размер архива) Цитата:
А для postgres нечто подобное есть? Больно уж крутая фича... Просто не верится, что она работает безпроблемно... |
|
|||
Просто желательно, чтобы все парсеры были на самом сайте - тогда можно будет использовать их не только для начальной обработки уже имеющихся фильмов, но и при добавлении новых в будущем.
Цитата:
Описание тут: http://www.postgresql.org/docs/8.3/s...extsearch.html Также есть универсальная библиотека полнотекстового поиска для MySQL и PostgreSQL под названием Sphinx (от ещё одного русского разработчика: Андрея Аксёнова). Там вроде даже морфология русского языка учитывается в запросах. http://www.opennet.ru/prog/info/3168.shtml Последний раз редактировалось AlexeyPetrov, 02.04.2008 в 14:56. |