Концепция Локальной коллекции - Страница 4 - Форум
LibRusLib
Суббота, 03.12.2016, 14:44
Приветствую Вас Гость | RSS
 
Главная Концепция Локальной коллекции - Страница 4 - ФорумРегистрацияВход
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 4 из 5«12345»
Архив - только для чтения
Форум » Архив "MultiLib - Библиотекарь" » Бета-тестирование » Концепция Локальной коллекции (Все вопросы, связанные со структурой, обработкой, хранением)
Концепция Локальной коллекции
drserjДата: Четверг, 01.08.2013, 13:47 | Сообщение # 46
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Цитата (1_абрам)
Но ты же пишешь: "Всё-таки меня интересует вопрос с одинаковыми именами в разных папках.", в чем проблема то?
 
Проблема в том, что если файл закатан в архив 1.zip и в другой папке есть тоже 1.zip - как понять, какой зип открывать. Т.е. прийдется тогда открывать архивы по-очереди, искать в них нужный файл по имени, считать и сравнивать мд5... А это долго. Особенно, если таких 1.zip будет много.
В идеале - надобно было бы еще и МД5 архива хранить, но это накладно. Да и в случае перепаковки (вдруг) МД5 изменится. 
Я не говорю что это сложно, просто хотелось бы ускорить поиск по максимуму...


drSerj
 
1_абрамДата: Четверг, 01.08.2013, 14:41 | Сообщение # 47
Генерал-полковник
Группа: Друзья
Сообщений: 989
Репутация: 0
Статус: Offline
А,  я   почему -то был уверен, что мы храним в базе пути к архиву.  Выходит хранится только имя файла и имя архива.  Тогда при большом количестве файлов поиск долго будет идти.

Для решения задачи,  можно запретить сканировние, если есть архивы с одинаковыми именами. Выдаем пользователю соответствующую информацию,  а он для того чтобы начать сканирование вынужден будет изменить имена совпадающих архивов.


Сообщение отредактировал 1_абрам - Четверг, 01.08.2013, 14:42
 
drserjДата: Четверг, 01.08.2013, 14:53 | Сообщение # 48
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Цитата (1_абрам)
А,  я   почему -то был уверен, что мы храним в базе пути к архиву.  Выходит хранится только имя файла и имя архива.  Тогда при большом количестве файлов поиск долго будет идти.

Ну ты же сейчас работаешь по этому алгоритму. И в либрус-библиотекаре  тот же алгоритм smile

Цитата (1_абрам)
Для решения задачи,  можно запретить сканировние, если есть архивы с одинаковыми именами.


Вооот....

Цитата (1_абрам)
Выдаем пользователю соответствующую информацию,  а он для того чтобы начать сканирование вынужден будет изменить имена совпадающих архивов.


А вот это неудобно. А в некоторых случаях (как у меня) - невозможно. Если на носителе, доступ к которому ридонли - как это сделать?
Я же говорю - единственный вариант - еще сохранять МД5 архива (ибо пути сохранять низзя), но это приводит к изменению структуры базы, чего тоже делать не хочется sad
Да и к архиву привязываться нельзя - из него можно удалить, скажем, дубли, и размер и МД5 изменятся...


drSerj
 
Alex_nooДата: Четверг, 01.08.2013, 15:21 | Сообщение # 49
Рядовой
Группа: Пользователи
Сообщений: 14
Репутация: 0
Статус: Offline
Цитата (drserj)
Проблема в том, что если файл закатан в архив 1.zip и в другой папке есть тоже 1.zip - как понять, какой зип открывать. Т.е. прийдется тогда открывать архивы по-очереди, искать в них нужный файл по имени, считать и сравнивать мд5... А это долго. Особенно, если таких 1.zip будет много. В идеале - надобно было бы еще и МД5 архива хранить, но это накладно. Да и в случае перепаковки (вдруг) МД5 изменится.  Я не говорю что это сложно, просто хотелось бы ускорить поиск по максимуму...
    Ой. Кажется, автор начинает понимать... что я ему десять раз повторил... :-D

Добавлено (01.08.2013, 16:12)
---------------------------------------------

Цитата (drserj)
(ибо пути сохранять низзя),
    У каждого свой религиозный догмат, да... :-(

Добавлено (01.08.2013, 16:21)
---------------------------------------------

Цитата (drserj)
Не надо передергивать. Я задал сообществу конкретный вопрос по структуре действий а не просил расписывать мнения обо всём и не о чем.
    Я о программе и говорил. Это и есть конкретный вопрос. Идеология и работа программы.
Цитата (drserj)
Да я вообще молчу. А по поводу "никто не юзает" - достаточно посмотреть статистику...  Короче, меня сейчас не интересуют разборки ху из ху, меня интересуют конкретные ответы на конкретные вопросы.
    Один Абрам. :-D
    Разборки меня вообще не интересуют. Меня интересует, чтобы было больше хороших каталогизаторов, и разных. Кто вам виноват, что вы мнения чужие не желаете воспринимать? И превращаете всё в разборку. :-(
    Конкретно и говорил я, про работу с локальными коллекциями.
 
drserjДата: Четверг, 01.08.2013, 15:32 | Сообщение # 50
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Цитата (Alex_noo)
Ой. Кажется, автор начинает понимать... что я ему десять раз повторил... :-D

Сообщения, не имеющие смысловой нагрузки приводят к бану... Данное сообщение информативным не является. Последнее китайское предупреждение.


drSerj
 
1_абрамДата: Четверг, 01.08.2013, 15:32 | Сообщение # 51
Генерал-полковник
Группа: Друзья
Сообщений: 989
Репутация: 0
Статус: Offline
Цитата (drserj)
А вот это неудобно. А в некоторых случаях (как у меня) - невозможно. Если на носителе, доступ к которому ридонли - как это сделать?


А в чем неудобство?  Можно, кстати, опционально делать это в автоматическом режиме:

c:/1/1.zip,  c:/1/1.zip -> c:/1/1.zip,  c:/1/1a.zip. А в случае "на носителе, доступ к которому ридонли - как это сделать"?  Ну ты же время от времени можешь туда писать.  Следовательно будешь писать с проверкой условия дублирования.  Утилитку можно сделать соответствующую.



Сообщение отредактировал 1_абрам - Четверг, 01.08.2013, 15:35
 
drserjДата: Четверг, 01.08.2013, 15:37 | Сообщение # 52
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Повторюсь, после добавления в базу ты захочешь изменить либо вообще расположение коллекции, либо ее части. Это приведет к полному нарушению работы программы. Пути сохранять низзя.
Простой пример, захотел я привести в порядок, сгруппировать книги на диске. При сегодняшнем раскладе - не вопрос. А вот если я привяжу к путям - всё, менять уже ничего нельзя.
По поводу переименования - не хорошо это.


drSerj
 
drserjДата: Четверг, 01.08.2013, 15:42 | Сообщение # 53
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Если бы в автоматическом режиме это делалось (как скачка в винде с добавлением цифры) - это еще как-то можно понять. А вот в данном случае... не знаю, не нравится мне такой подход.
При таком раскладе уже проще в имени добавленного файла какую-нить пометку делать, типа подчеркивания в начале или конце (к примеру)...

О... идея... гы... а если создавать текстовик со списком уже добавленных файлов, в каждом каталоге? Хотя я как-то читал недовольство по поводу такого подхода, да и с рид-онли разделом такое не прокатит sad


drSerj
 
1_абрамДата: Пятница, 02.08.2013, 09:13 | Сообщение # 54
Генерал-полковник
Группа: Друзья
Сообщений: 989
Репутация: 0
Статус: Offline
Цитата (drserj)
Добавляем в базу всё, что парсится. Всё, что не парсится - в отсев на доработку. А уже в актуализации можно будет добавить поиск дублей.


Там же можно и искать архивы с совпадающими именами логично это назвать на актуализацией, а валидацией данных.  Жанные валидны, если нет дублей книжек и архивов.   В этом случае гарантируется корректная работа программы.  Ну мне все таки больше нравится запрет сканирование при наличие  архивов с одинаковыми именами.

Добавлено (02.08.2013, 10:13)
---------------------------------------------

Цитата (drserj)
Повторюсь, после добавления в базу ты захочешь изменить либо вообще расположение коллекции, либо ее части. Это приведет к полному нарушению работы программы. Пути сохранять низзя.


 
Полносью согласен,  хотя наличие путей увеличиват скорость поиска.

 
Кстати,  о поиске.  А не ввести ли в приватные библиотеки  bookId  (присваивается  при добавлении книжки в базу).  Когда библиотека разрастается, то можно формировать архивы тысячники  (как в на флибусте и генезисе) и решить проблему скорости поиска.


Сообщение отредактировал 1_абрам - Пятница, 02.08.2013, 09:20
 
drserjДата: Пятница, 02.08.2013, 10:17 | Сообщение # 55
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Цитата (1_абрам)
Кстати,  о поиске.  А не ввести ли в приватные библиотеки  bookId

А что, их нет???? smile Куда ж без них, однако... Есть они... Можешь даже в таблице посмотреть smile

Цитата (1_абрам)
Там же можно и искать архивы с совпадающими именами логично это назвать на актуализацией, а валидацией данных.  Жанные валидны, если нет дублей книжек и архивов.   В этом случае гарантируется корректная работа программы.  Ну мне все таки больше нравится запрет сканирование при наличие  архивов с одинаковыми именами.


Это опять грустно... Я вот подумал, слепить дополнительную табличку скана, в которой будут храниться имя архива и его размер (может и мд5). И тупо в нее вносить при добавлении в базу. А при последующем сканировании (можно в настройках отключить) все архивы, попадающие под понятие дубль будут просто пропускаться. Тут ведь причина подобного процесса - ситуация с пополняемыми каталогами. Если бы книги добавлялись из стороннего каталога - проблем не было бы. А так - сканируется уже ранее обработанный каталог. Ну а если этот каталог в процессе работы с программой кто-то перепаковал, изменился размер - будет пересканирован.


drSerj
 
1_абрамДата: Пятница, 02.08.2013, 11:34 | Сообщение # 56
Генерал-полковник
Группа: Друзья
Сообщений: 989
Репутация: 0
Статус: Offline
Цитата (drserj)
Это опять грустно... Я вот подумал, слепить дополнительную табличку скана, в которой будут храниться имя архива и его размер (может и мд5).


Это конечно оптимальное решение, размера, наверное, достаточно.

Добавлено (02.08.2013, 12:34)
---------------------------------------------

Цитата (drserj)
А что, их нет???? Куда ж без них, однако... Есть они... Можешь даже в таблице посмотреть


 
Виноват, просмотрел, действительно есть.  Значит для локальной библиотеки можно формировать архивы тысячники с быстрым поиском?
 
drserjДата: Пятница, 02.08.2013, 12:15 | Сообщение # 57
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Цитата (1_абрам)
Значит для локальной библиотеки можно формировать архивы тысячники с быстрым поиском?

Ну, в принципе, да... только перед сканированием и добавлением smile Хотя, зачем такое надо в приватной библиотеке???

Цитата (1_абрам)
Это конечно оптимальное решение, размера, наверное, достаточно.

Да вот и я думаю, что достаточно...


drSerj
 
1_абрамДата: Пятница, 02.08.2013, 14:31 | Сообщение # 58
Генерал-полковник
Группа: Друзья
Сообщений: 989
Репутация: 0
Статус: Offline
Цитата (drserj)
Ну, в принципе, да... только перед сканированием и добавлением Хотя, зачем такое надо в приватной библиотеке???


А почему  "только перед сканированием и добавлением ",  что bookId формируется каждый раз заново?

 
Ты же сам писал, что приватная библиотека может быть большой.  При 100 тыс. книжек поиск будет очень медленным, имхо.
 
 

 
drserjДата: Пятница, 02.08.2013, 15:08 | Сообщение # 59
Генералиссимус
Группа: Администраторы
Сообщений: 3865
Репутация: 24
Статус: Offline
Цитата (1_абрам)
А почему  "только перед сканированием и добавлением ",  что bookId формируется каждый раз заново?

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

Единственный вариант, позволяющий хранить на диске файлы независимо от нахождения/ненахождения в архиве, независимо от папок - вариант Имя файла =БукИД, имя архива - завязано на букИД (равно или входит в промежуток). Но, поскольку многие против переименований, переносов и т.д. - делать такой вариант смысла не имеет. Хотя, себе я бы избрал именно такой вариант.

Впрочем, никто не мешает написать плаг, который будет работать именно по принципу, описанному выше. В этом и прелесть новой программы smile

Цитата
Ты же сам писал, что приватная библиотека может быть большой.  При 100 тыс. книжек поиск будет очень медленным, имхо.

Ну, во-первых, надо сначала думать, потом делать smile А потом, кто мешает создавать подкаталоги? Формирование структуры - дело рук пользователей.


drSerj
 
1_абрамДата: Пятница, 02.08.2013, 16:03 | Сообщение # 60
Генерал-полковник
Группа: Друзья
Сообщений: 989
Репутация: 0
Статус: Offline
Цитата (drserj)
А как иначе? Мы же договорились, файл может иметь любое имя. Если бы все согласились с переименование и унификацией - да, такой вариант бы прошел, а так - имеем, что имеем...


А если такой алгоритм поиска.
 
Сначала ищем файл в хранилище (там файлы хранятся  в описанном тобой формате), если находим поиск прекращается.  Если нет, то ищем в подключенных папках.  Архивы тысячники формируются время от времени пользователем,  исполоьзую однозначную связь мд5  -  bookId.   Наличие дублей на усмотрение пользователя.
 
Я всегда думал что именно так и работает поиск в либруслибе.
 
 
 

Добавлено (02.08.2013, 17:03)
---------------------------------------------

Цитата (drserj)
А потом, кто мешает создавать подкаталоги? Формирование структуры - дело рук пользователей.

  А как подкаталоги ускорят поиск?
 
Форум » Архив "MultiLib - Библиотекарь" » Бета-тестирование » Концепция Локальной коллекции (Все вопросы, связанные со структурой, обработкой, хранением)
Страница 4 из 5«12345»
Поиск:

Copyright LibRusLib © 2016