Чи погана практика зберігати інформацію метаданих у назвах файлів? Кращі рішення?

Я помітив, де я працюю, люди хочуть зберігати інформацію в іменах файлів та аналізувати імена файлів.

Мені це здається не особливо хорошою практикою. Я вже бачу випадкові проблеми зі скриптами, які поширюються на файл, і отримують неправильний, оскільки перший файл відповідає першим. Ми також обговорюємо, як вирішити проблеми з роздільниками для полів.

Це вважається поганою практикою чи ні?

Які ще прийняті рішення для отримання файлів з файлової системи на основі певного типу метаданих?

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

Краще використовувати «головний файл» (іноді його називають маніфестом чи індексом), який містить метадані та шляхи до файлів. Або щось подібне в базі даних, реєстрі чи що. Або розмістити метадані всередині фактичних файлів, на верхньому рівні якоїсь структури даних, що міститься у файлі, наприклад, JSON або XML.

Це дещо аналогічно концепції розміщення інформації або клавіш простору імен у сховищах ключових значень. Я думаю, що це нормально, якщо ви використовуєте його лише для простору імен та швидкого пошуку - ключових компонентів немає для того, щоб забезпечити проаналізовану інформацію. Якщо вам потрібна ця інформація, скопіюйте її у значення (файл у вказаному випадку).

По-перше, метадані - це розмита концепція.

Однак, багато випадків метаданих у файлах вже є:

• номери версій бібліотек
• дата та час зображення або принаймні індекс послідовності
• тип файлу, який запускає, яка програма повинна відкрити файл
• назва вашого домашнього каталогу, який повинен бути вашим іменем користувача сесії

Тим не менш, цей короткий список не є аргументом на користь практики.

Альтернативи:

• обробляти метадані на рівні FS, як, наприклад, стара HFS Apple
• помістити метадані у сам файл, як Exif для зображень або ID3 для звуків
• помістити метадані в інший файл або в базу даних, як і більшість медіа-менеджерів.

Це здається, що вам потрібна база даних.

Існує багато проблем із безпекою щодо введення даних користувачів у імена файлів. Скажімо, у вас є файл для кожного користувача ("username.txt"). Що відбувається, коли хтось реєструє ім'я користувача "../../../../etc/passwd", залежить від того, як ви фільтруєте введення користувача.

Структури баз даних іноді допоможуть вам провести санітарний ввід користувача.

Ні ... ну .. не обов’язково.

Поки у вас є чітка конвенція та загальні засоби розбору та перевірки (скрипти, бібліотеки тощо), які легко доступні, ви готові йти.

Візьмемо для прикладу системи управління упаковкою та залежностями (Maven, NuGet тощо). Хоча багато хто використовуватиме конкретні файли для метаданих для зберігання більш вдосконаленої інформації, основна інформація часто є частиною самого імені файлу. Спираючись на суворі умови, ім'я файлу може містити найбільш релевантну інформацію про пакет: це постачальник, ім'я, версія, тип. Іноді це все, що вам потрібно ... 4 або 5 коротких відомостей.

Якщо метадані прості, то домовленість про іменування файлів має ідеальний сенс, що нічого не потрібно встановлювати. Його можна підсилити за допомогою дуже простих інструментів та скриптів, не потрібна база даних, спеціалізована інфраструктура, лише кілька сценаріїв та умовне іменування.

Якщо нічого там зовсім не те, що вам потрібно, і ваші потреби прості, я б почав з цього.

ваші вимоги перевищують цю конвенцію? розгорніть його відповідним файлом метаданих. Пізніше вам потрібен кращий пошук для цього? Там уже є хороші рішення для пошуку файлів, які приведуть вас туди, де вам потрібно.

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

Ніколи не варто недооцінювати потужність низьких технологій при належному нагляді, це може дати вам довгий шлях.

А до того часу, як ви переростете своє низькотехнологічне рішення, ви зібрали весь досвід та вимоги для впровадження ідеальної системи для ваших потреб.

По- перше, давайте домовимося , що файл знаходиться . Файл - це упаковані дані з іменем, яке можна передавати, отримувати, створювати та видаляти за допомогою (дуже близьких до) атомних операцій.

Багато файлових систем (Mac OS та новіших файлових систем Linux) реалізують "вилки", які часто використовуються для зберігання ресурсів та метаданих. Такий підхід до зберігання метаданих був проблематичним тим, що традиційні методи передачі мережі, способи резервного копіювання та відновлення та методи копіювання файлів були непослідовними, особливо коли файлові системи джерела та місця призначення по-різному розуміли файлові форки.

Ім'я файлу використовується для зберігання метаданих, оскільки: а) воно завжди є; б) метадані завжди були присутні в імені файлу (принаймні, при використанні розширень файлів); ​​в) ім'я файлу зазнає дуже мало перекладу при переміщенні між системами (відмінність регістру, обмеження набору символів, обмеження символів убік).

Отже, ім'я файлу є видимим, портативним та керованим. Це не погано для зберігання деяких метаданих.

Мабуть, найкращим рішенням для вирішення загальних метаданих файлів є використання сховища вмісту , де сховище вмісту може бути налаштоване за допомогою схеми метаданих, яка використовується для файлів. У багатьох випадках це надмірність, але, IMHO, це шлях до серйозного управління метаданими.

Я вважаю, що ви, можливо, десь бачили код, який робить неохайні або крихкі речі з іменами файлів, але це не означає, що "зберігання метаданих у назви файлів" взагалі погано.

Назви файлів є метаданими - це дані про дані у файлі, незалежно від самих даних файлу. Насправді назви файлів настільки старі, що вони, мабуть, є канонічним прикладом метаданих.

Якщо ви вважаєте, що розширення файлів є лише кінцевою частиною імені файлу, тоді концепція імені файла як метаданих стає ще більш неминучою.