Open GoogleCodeExporter opened 8 years ago
Вопрос конечно интересный. Главная
проблема: как в коллекции будут уживаться
попса и
матёрая классика? У них же предполагаются
почти непересекающиеся множества данных.
На вскидку могу предложить в набор
существующих полей (там около семи полей из
тегов)
проецировать произвольные теги id3v2.4 или ogg.
Если этого мало, то надо думать дальше.
Original comment by drmoriar...@gmail.com
on 2 Jun 2009 at 10:14
Второй вариант на вскидку. Реализовать
дополнительную схему. Основная схема
заполняется как есть (для попсы).
Дополнительная задаётся произвольным
набором
упорядоченных полей. И сделать два режима
плейлиста, для отображения основного
набора
и дополнительного. Единственно что, не
представляю пока как сделать удобную
выбиралку
в коллекции по расширенному набору.
Original comment by drmoriar...@gmail.com
on 2 Jun 2009 at 11:29
Ко второму варианту я уже подумываю о
произвольном количестве отдельных
коллекций, для
каждой из коллекций свои параметры
каталогизации. Было бы логичным развитием,
я
полагаю.
> Единственно что, не представляю пока как
сделать удобную выбиралку в коллекции по
расширенному набору.
Если говорить про удобство для
пользователя и хотеть сохранить
представление, которое
есть сейчас, то можно, наверно, сделать так:
1. там, где мы задаём поля, по которым вести
каталогизацию, позволить расставить
галочки "узел" (или как-нибудь так) напротив
нескольких полей
2. после сканирования каталогов или
пересканирования файлов на вкладке
"коллекция"
отображаются кнопки нодов/узлов/however, но
пока что в виде надписей. Поведение этих
кнопок такое же, как сейчас у genre/artist/album/track
3. правая кнопка мыши или дополнительное
меню на этих кнопках / в этой вкладке
позволяет задать иконки
узлам/нодам/как_их_там и отсортировать их в
произвольном
прорядке (создаёт видимость иерархичности)
// 4. возможно - было бы интересно, но не факт,
что вообще реализуемо - объединение
нескольких нодов в одну кнопку. Наверно,
всё-таки ненужно, придумать полезного
примера
не смог.
Original comment by nomen.in...@gmail.com
on 2 Jun 2009 at 1:20
Возможно, я не учёл того, что тебе хотелось
бы не трогать существующий способ хранения
и представления информации. Потому что
если говорить о "произвольном колчестве
коллекций" - то тут имеющуюся таблицу Song
sqlite> .schema Song
CREATE TABLE Song (ID integer primary key autoincrement, File varchar(250),
Track
integer, Title varchar(200), Artist integer, Album integer, Genre integer, Year
integer, Comment varchar(200), Length varchar(20), Rating integer);
придётся прекроить. И я полагаю, что при
любых изменениях её придётся перекраивать,
либо делать другую таблицу рядом.
Поэтому предлагаю сразу её перекроить. Я
вообще привык, что у нас (у меня на работе)
подобная информация разбивается на
несколько таблиц. Таблица номер 1 - словарь.
Что-
то типа такого:
sql++> desc dict;
+-------------+----------+---------------+
| Name | Null? | Type |
+-------------+----------+---------------+
| DICT_ID | NOT NULL | NUMBER(22) |
| TYPE_ID | NOT NULL | NUMBER(22) |
| FORMAT_ID | NOT NULL | NUMBER(22) |
| ATTRIBUTE | NOT NULL | VARCHAR2(255) |
| CTL_TYPE | | VARCHAR2(255) |
| DFL_VAL | | VARCHAR2(255) |
| DESCRIPTION | | VARCHAR2(255) |
+-------------+----------+---------------+
7 rows in set (0.051 secs)
нам, конечно, ctl_class и def_val не нужны, но смысл
понятен. Можно сделать поля
DICT_ID, VORBIS_COMMENT, ID3_FIELD, DESCRIPTION или что-то
подобное.
Вторая таблица - основные данные, которые
нужны при любом способе каталогизации.
Например, это имя файла, номер коллекции и
уникальный идентификатор (id). Третья
таблица - это, соответственно, паспорт.
Например:
desc SERVICES_EXT;
+-----------------+----------+---------------+
| Name | Null? | Type |
+-----------------+----------+---------------+
| SERVICES_EXT_ID | NOT NULL | NUMBER(22) |
| SERVICE_ID | NOT NULL | NUMBER(22) |
| DICT_ID | NOT NULL | NUMBER(22) |
| VALUE | | VARCHAR2(255) |
| DATE_BEG | NOT NULL | DATE(7) |
| DATE_END | | DATE(7) |
+-----------------+----------+---------------+
6 rows in set (0.006 secs)
таблицы, конечно же объединены индексами и
констрэинтами.
Original comment by nomen.in...@gmail.com
on 2 Jun 2009 at 1:37
Попробую для тренировки существующую
схему переделать на новые рельсы. Вообще
такая
организация как бы напрашивается, но лень
всему виной.
Original comment by drmoriar...@gmail.com
on 3 Jun 2009 at 6:43
Original issue reported on code.google.com by
nomen.in...@gmail.com
on 1 Jun 2009 at 5:51