Блог

У меня есть тысячи файлов PDF, к которым в основном обращаются программно. Это академические документы, и их имена начинаются с <the last name of the author in letter><optional digit(s) to distinguish different authors of the same name><period><year><optional letter(s) to distinguish different documents of the same author-year> ) вот так:

 Johns1.2000a.pdf
  

С точки зрения программирования соответствующих программ проще, если все эти файлы находятся в одном каталоге.

Однако, когда я иногда открываю эти файлы вручную в файловом браузере с графическим интерфейсом, каталог настолько огромен, что реакция файлового браузера замедляется. Из-за этого я разделил файлы на подкаталоги, названные по начальной букве имени файла (т. Е. Файл Johns....pdf Переходит в подкаталог J и т. Д.). Но

• Интересно, имеет ли смысл это делать,

а также проблемы с этим методом.

• Во-первых, имена файлов распределены неравномерно по отношению к начальной букве; на некоторые буквы начинается больше файлов, а на некоторые меньше.
• Во-вторых, если коллекция файлов будет расти, каждый подкаталог станет слишком большим, и мне придется перейти на другой уровень, например AA , AB , …, который
  • является произвольным и специальным (мне пришлось бы вручную добавлять уровень всякий раз, когда я чувствую, что подкаталоги стали слишком большими), и
  • несбалансированное распределение стало бы еще хуже (т. Е. В каталоге редко были бы какие-либо файлы QQ , но KA , например, их было бы довольно много).

В этой ситуации,

1. Имеет ли смысл вообще создавать подкаталоги? Я лишь изредка обращаюсь к файлам вручную, поэтому могу смириться с медленным откликом файлового браузера. С другой точки зрения, есть ли какие-либо плюсы для этого?
2. Если имеет смысл создавать подкаталоги, есть ли метод, у которого нет проблем, упомянутых выше?

Внимание: я просто думаю о своей голове. Это относится только к вашему вопросу № 2.

Предположим, вы сопоставили имя каждого файла с его хэш-кодом и сохранили файл в структуре каталогов, основанной на хэш-кодах? Например,

 str = "Johns1.2000a.pdf"

str.hash.abs.to_s.chars
  #=> ["5", "2", "2", "1", "9", "8", "0", "3", "1",
  #    "6", "9", "8", "3", "0", "8", "1", "5", "2"]
  

таким образом, этот файл может храниться как

 /5/2/2/Johns1.2000a.pdf
  

Вы могли бы использовать такие правила, как следующие:

• сначала создайте каталоги /1 , /2 ,…, /9 и добавьте файлы в эти каталоги на основе первой цифры абсолютного значения их хэш-кодов.

• при сохранении файла, если подкаталог d уже содержит N файлы ( N являющиеся параметром), создайте подкаталоги /0 , /1 , /2 ,…, /9 of d и переместите каждый файл в d соответствующий подкаталог на основе его хэш-кода. В приведенном выше примере файл Johns1.2000a.pdf будет перемещен из /5/2/2/Johns1.2000a.pdf в /5/2/2/1/Johns1.2000a.pdf .

• чтобы извлечь файл, перейдите к последнему подкаталогу на основе хэш-кода файла.

• вы могли бы периодически ходить по дереву, чтобы увидеть, содержит ли какой-либо подкаталог предпоследнего уровня d только пустые подкаталоги, и в этом случае d все подкаталоги могут быть удалены. В качестве альтернативы, каждый каталог может содержать файл, содержащий подсчет общего количества файлов в его непосредственных подкаталогах, который будет обновляться при добавлении или удалении файлов. Когда счетчик становится равным нулю, подкаталоги могут быть удалены.

Пара замечаний:

• это, очевидно, требует, чтобы алгоритм вычисления хэш-кодов не менялся в будущем. Если есть какая-либо вероятность, что это может произойти, вы можете использовать пользовательский метод хэш-кода.

• Я предполагаю, что первые несколько цифр в абсолютном значении хэш-кода будут распределены почти случайным образом, но если нет, то последние несколько цифр хэш-кода наверняка будут.