Форум » Основной форум » Проект новой поисковой » Ответить

Проект новой поисковой

raindog: Возможно, не все коллеги следят за обсуждением в соседнем разделе. С 1 февраля планируется закрытие старой поисковой системы. Bete_Noire тестирует новую систему здесь: http://mtsearch.hut2.ru/index.php. Присоединяйтесь к тестированию и обсуждению! Обсуждение в вышеуказанной ветке.

Ответов - 206, стр: 1 2 3 4 5 6 7 8 9 10 11 All

Croc: ...цветовую маркировку альбомов по качеству и т.п. Началось... Сначала сделали хорошую поисковую систему, теперь начнем превращать ее в монстра. Качество, конечно, умники начнут определять по битрейту. А "глюки MPEG Audio Collection" пользователи в состоянии исправить и сами. Зачем лезть с услугами, когда не просят.

Bete_Noire: Сначала сделали хорошую поисковую систему, теперь начнем превращать ее в монстра. это был всего лишь пример. я сам не любитель "монстров". чтоб понятней было приведу другую причину - меньше вариантов - меньше физический размер базы (при соответствующей структуре). А "глюки MPEG Audio Collection" пользователи в состоянии исправить и сами. Зачем лезть с услугами, когда не просят. зарегистрировано всего 7 пользователей, а я уже с уверенностью могу сказать, что не все в состоянии....

raindog: стандартизация, сведение вариантов к разумному минимуму всегда имеет смысл. в дальнейшем это может упростить группировку, цветовую маркировку альбомов по качеству и т.п. Строго говоря, группировка и маркировка может осуществляться при отображении, не обязательно менять сами отображаемые или вносимые значения. Насколько я понимаю, замечание Croc можно понять и так. мда, бывают еще и такие. Вообще, хорошо бы понять, что там вообще бывает. Здесь два вопроса. 1) Понятно, что у нас есть записи о данных трех родов 1.1) lossless-аудио, 1.2) lossy-аудио и 1.3) видео. Крайне желательно, чтобы система их различала, позволяла сортировать записи по этому признаку и ограничивать поиск одним или несколькими родами данных. Это востребовано. 2) Внутри каждого из них могут быть разные типы данных. 2.1) Lossless-аудиоданные могут быть образом CD-DA или DVD-audio, кроме того,могут быть представлены в разных форматах. 2.2) Lossy-аудиоданные различаются форматом и битрейтом. 2.3) Видеоданные вообще непонятно как классифицировать. Востребована пока лишь сортировка (или отсечение) Lossy-аудиоданных по битрейту. Насколько востребована "монстроидальность", которую можно дополнительно здесь накрутить, пока неясно. человек нашел в поисковой что ему надо пошел на сайт трейдера и договорился об обмене. вебринга в этой цепочке нет! не хорошо как-то получается. Строго говоря, ринг --- это не страница со списками, а совокупность сайтов-участников. В старой поисковой вопрос связности решается тем, что сама страница поисковой интегрирована в заглавную страницу ринга как один из фреймов. Так что мячик на стороне операторов ринга. кроме того далеко не все захотят заполнять большинство полей, в результате будут одни дыры. Строго говоря, не факт, что эти сведения нужно отображать в табличной форме.


raindog: меньше вариантов - меньше физический размер базы (при соответствующей структуре) На этом много не сэкономишь. Если нужно будет резать размер, идти, скорее всего, придется по пути вынесения пары "Исполнитель-Альбом" в отдельную таблицу, а затем, возможно, "^(Исполнитель-Альбом), битрейт" также в отдельную. Это уменьшит размер, но не факт, что оптимизирует производительность по сравнению с одной правильно индексированной таблицей. И вообще, все это обсуждать можно будет только имея доступ к развернутой статистике; уж полсотни участников и сотню тысяч записей для этого нужно иметь.

Bete_Noire: группировка и маркировка может осуществляться при отображении, не обязательно менять сами отображаемые или вносимые значения. преобразовывать один раз при внесении или каждый раз для каждого пользователя? по-моему разница есть. Крайне желательно, чтобы система их различала, позволяла сортировать записи по этому признаку и ограничивать поиск одним или несколькими родами данных. это будет намного проще реализовать имея в базе только приведенные битрейты. На этом много не сэкономишь. Если нужно будет резать размер, идти, скорее всего, придется по пути вынесения пары "Исполнитель-Альбом" да я это и имел в виду, резать даже не по парам, а иметь отделные базы артистов, битрейтов, альбомов и связывать их по индексам. ну пока это особого смысла не имеет, но о будущем тоже надо думать.

Алексей: Спасибо создательям новой поисковой за отличную работу. Имею небольшое пожелание, чтобы колонка битрейт допускала отображение формата в виде "320 / FLAC" и входила как в категорию Lossless так и в Lossy. А то у меня все альбомы Lossless имеют дубликаты mp3.

Bete_Noire: чтобы колонка битрейт допускала отображение формата в виде "320 / FLAC" и входила как в категорию Lossless так и в Lossy. А то у меня все альбомы Lossless имеют дубликаты mp3. по поводу битрейтов никак не выработаем единой концепции. давать вводит такие битрейты на мой взгляд не целесообразно. один трейдер захочет вводить битрейты через слэш, другой через тире, третий через запятую.... В таком случае лучше дублировать альбомы с указанием разных битрейтов.

Алексей: по поводу битрейтов никак не выработаем единой концепции А что если отбросить концепции и пустить колонку битрейта как есть?

Bete_Noire: боюсь тогда можно забыть о фильтре по битрейту при поиске (lossless/lossy/video).

Croc: боюсь тогда можно забыть о фильтре по битрейту при поиске (lossless/lossy/video). Ну уж, прям уж... Вылавливать "ape", "flac", "cdda" можно при любом указании битрейта. И даже из строки типа "320 / flac". Будет фильтр не (lossless/lossy/video), а (lossless/video/БезФильтра)...

Bete_Noire: Ну уж, прям уж... Вылавливать "ape", "flac", "cdda" можно при любом указании битрейта. можно конечно. просто куда проще это сделать единожды обработав поле при вводе, чем потом составлять хитрые запросы при каждом поиске. ну да ладно, смотрю не очень хорошо идею с округлением битрейтов приняли, считайте, что переубедили ) округление оставляем только при наличии в битрейте CBR, для ABR и VBR отключаем. В таком варианте округление будет производится только если пользователь недоглядел и не поправил 319->320. На счет двух битрейтов в одном поле... один экземпляр альбома - одна запись. если у трейдера 2 экземпляра альбома пусть продублирует запись. в этом нет ничего сложного. можно считать это правилом добавления списков.

raindog: http://mtsearch.onep.ru/index.php: 10 популярных запросов верка сердючка дима билан руки вверх ... Похоже, у нас проблемы с позиционированием :)

Bete_Noire: Похоже, у нас проблемы с позиционированием :) да уж. будем надеяться что это только кто-то тестирует систему )

ewer: Хорошо бы указывать "границы" поиска: по исполнителю, по альбому, по исполнителю+по альбому (как сейчас). Когда база не велика - нормально. Но в дальнейшем это будет загромождать весь экран...

raindog: Да, в перспективе это неплохо бы иметь.

Bete_Noire: Хорошо бы указывать "границы" поиска: по исполнителю, по альбому, по исполнителю+по альбому приделал.

YuriySt54: Вроде зарегистрировался, а войти не могу. Всего 8 знаков вбивается, а у меня 9. Косяк?

Bete_Noire: Вроде зарегистрировался, а войти не могу. Всего 8 знаков вбивается, а у меня 9. Косяк? В чём 9 знаков, в нике? Ник при регистрации нигде не фигурирует, вводить в качестве логина надо ID на вебринге. Это численное значение, у меня например 326.

YuriySt54: Блин, тормознул. Прошу прощения

Bete_Noire: Блин, тормознул. бывает, с успешной регистрацией )



полная версия страницы