É uma prática recomendada armazenar informações de metadados nos nomes dos arquivos? Melhores soluções?


13

Percebi que onde trabalho, as pessoas gostam de armazenar informações em nomes de arquivos e analisar os nomes dos arquivos.

Para mim, isso não parece ser uma boa prática. Eu já vejo problemas ocasionais com scripts que ficam ocultos em um arquivo e estão errando porque outro arquivo corresponde primeiro. Também estamos discutindo como contornar problemas com separadores para os campos.

É considerado má prática ou não?

Quais são as outras soluções aceitas para recuperar arquivos de um sistema de arquivos com base em algum tipo de metadado?


Depende muito do que exatamente está sendo armazenado no nome do arquivo. Você pode nos dar alguns exemplos?
T. Sar - Restabelece Monica

Respostas:


14

Sim, acho que é uma prática ruim. Está sujeito a todos os tipos de problemas - por exemplo, limites de comprimento, problemas de codificação e conflitos devido a dados duplicados.

Melhor é usar um "arquivo mestre" (às vezes chamado de manifesto ou índice) que contém metadados e caminhos para os arquivos. Ou algo semelhante em um banco de dados, registro ou outros enfeites. Ou, para colocar os metadados nos arquivos reais, no nível superior de alguma estrutura de dados contida no arquivo, por exemplo, JSON ou XML.

Isso é um pouco análogo ao conceito de colocar informações ou chaves de namespacing nos armazenamentos de valores-chave. Acho que está tudo bem, desde que você o use apenas para namespace e faça pesquisas rápidas - os principais componentes não estão lá para fornecer informações analisáveis. Se você precisar dessas informações, duplique-as no valor (arquivo no caso acima).


3
Você está levantando pontos no estômago. Mas há situações em que, no entanto, faz sentido colocar as informações no nome do arquivo. Pense em anexos de email que precisam ser roteados ou processados ​​de maneira baseada em regras. Se muitos processos paralelos precisarem alterar o arquivo mestre, isso poderá se tornar um gargalo.
quer

Como desenvolvedor de banco de dados, naturalmente penso em usar um banco de dados em vez de um arquivo de manifesto (um dos motivos pelos quais peço aqui métodos alternativos). Isso resolveria o problema de acesso simultâneo, mas é uma solução mais complexa.
Wobily_col #

1
@wobbily_col, dependendo do sistema que você usa, pode haver suporte para atributos de arquivo estendidos disponíveis.
Hellion

@AxelKemper Há tanta informação que você pode incluir em um nome. Há mais metadados que o nome e o autor.
Tulains Córdova

Sem mencionar que os nomes de arquivos podem ser alterados por alguém fora do seu sistema, quebrando os formatos esperados. Mesmo quando você tem as permissões de arquivo apropriadas aplicadas, acaba sendo uma solução quebradiça.
Berin Loritsch 17/06/19

5

Primeiro, os metadados são um conceito embaçado.

Dito isto, já existem muitos casos de metadados em arquivos:

  • números de versão das bibliotecas
  • data e hora das imagens ou, pelo menos, índice de sequência
  • tipo de arquivo, que aciona qual aplicativo deve abrir o arquivo
  • nome do diretório inicial, que deve ser o nome de usuário da sua sessão

No entanto, essa lista curta não é um argumento a favor da prática.

As alternativas são:

  • manipular metadados no nível FS, como o HFS antigo da Apple, por exemplo
  • coloque metadados no próprio arquivo, como Exif para imagens ou ID3 para sons
  • coloque metadados em outro arquivo ou em um banco de dados, como a maioria dos gerenciadores de mídia.

5
Tudo é um conceito embaçado. Mesmo "embaçado", "conceito" e "tudo" são conceitos embaçados.
Tulains Córdova

3

Parece que você precisa de um banco de dados.

Existem muitos problemas de segurança ao colocar dados do usuário em nomes de arquivos. Digamos que você tenha um arquivo para cada usuário ("nomedeusuário.txt"). O que acontece com o que alguém registra o nome de usuário "../../../../etc/passwd" depende de como você está filtrando a entrada do usuário.

As estruturas de banco de dados às vezes o ajudam a limpar a entrada do usuário.


Na verdade, muitos sistemas operacionais armazenam nomes de usuários em nomes de diretório, chamados de diretório inicial .
Mouviciel

Isso porque alguns softwares precisam estar no fundo da pilha. Isso não significa que todos tenham que trabalhar nesse nível. Não vou discutir o mérito dos bancos de dados, porque os programadores os usam há mais de 50 anos.
11133 Eric Wimberley

1
@mouviciel Não conheço nenhum sistema operacional que analise o nome do usuário no nome do diretório inicial do usuário. Os sistemas Windows e Unix-like armazenam o nome do diretório em algum tipo de banco de dados e o carregam no ambiente quando o usuário efetua login. Nos dois sistemas, você pode acabar com o nome do diretório inicial diferente do nome do usuário ( por exemplo, renomear usuários ou se você tiver duas instalações do Windows na mesma partição do sistema).
Jules

2

Não ... bem ... não necessariamente.

Contanto que você tenha uma convenção estrita e meios comuns de análise e validação (scripts, bibliotecas etc.) prontamente disponíveis, você estará pronto.

Tomemos, por exemplo, sistemas de gerenciamento de pacotes e dependências (Maven, NuGet e similares). Embora muitos usem arquivos específicos para metadados para armazenar informações mais avançadas, as informações básicas geralmente fazem parte do próprio nome do arquivo. Confiando em convenções estritas, o nome do arquivo pode conter as informações mais pertinentes sobre o pacote: é fornecedor, é nome, é versão, é tipo. Às vezes é tudo o que você precisa ... 4 ou 5 pequenas informações.

Se os metadados são simples, uma convenção de nomenclatura de arquivos faz todo o sentido, exigindo que nada seja implementado. Ele pode ser reforçado com ferramentas e scripts muito simples, sem necessidade de banco de dados, sem infraestrutura especializada, apenas alguns scripts e uma convenção de nomenclatura.

Se nada lá fora realmente faz o que você precisa e suas necessidades são simples, eu começaria com isso.

seus requisitos superam esta convenção? estenda-o com um arquivo de metadados adequado. Mais tarde, você precisa procurar melhor por isso? Já existem boas soluções para procurar arquivos que o levem aonde você precisa.

Não é que eu não goste de bancos de dados, pelo contrário, eles são realmente poderosos e úteis, mas exigem uma certa quantidade de sobrecarga para continuar. Eles precisam ser instalados, armazenados em backup, mantidos. Você precisará de uma equipe que, se não for totalmente dedicada, precisará dedicar parte do tempo a essa infraestrutura. Eles também são mais complexos e enigmáticos para os leigos, perdem o desenvolvedor que o configurou e seu sistema ficará parado no tempo até você encontrar um substituto.

Nunca subestime o poder da baixa tecnologia com a supervisão adequada, pois isso pode levá-lo a um longo caminho.

E quando você superar sua solução de baixa tecnologia, terá reunido toda a experiência e requisitos para implementar o sistema perfeito para suas necessidades.


Nunca subestime o poder da inércia. Transformar uma solução de baixa tecnologia em algo mais robusto requer muito mais esforço do que simplesmente não fazê-lo dessa maneira, para começar.
Berin Loritsch

1
O mesmo argumento do @BerinLoritsch se aplica a todas as soluções, de baixa tecnologia ou hitech ... pode-se argumentar que o hitech que exige mais interdependência de sistemas realmente torna essa situação pior, não mais fácil. Dito isto, existe um limiar em que uma solução simples de baixa tecnologia se torna mais complicada do que sua contrapartida de alta tecnologia.
Newtopian

1
Sim, e estou desamarrando alguns exemplos em um projeto agora. Resumindo, é necessário que haja uma interface mais rígida do que o sistema de arquivos mais vezes do que não. Infelizmente, a maioria dos sistemas de baixa tecnologia que eu herdo não possui pensamento ou design apropriado aplicado a eles. O número de exceções que posso contar por um lado.
Berin Loritsch

0

Primeiro, vamos concordar que um arquivo é . Um arquivo é um dado empacotado com um nome que pode ser transmitido, recebido, criado e excluído com operações atômicas (muito próximas a).

Muitos sistemas de arquivos (Mac OS e sistemas de arquivos Linux mais recentes) implementam "garfos", geralmente usados ​​para armazenar recursos e metadados. Essa abordagem para armazenar metadados era problemática, pois os métodos tradicionais de transferência de rede, os métodos de backup e restauração e os métodos de cópia de arquivos eram inconsistentes, especialmente quando os sistemas de arquivos de origem e de destino entendiam os garfos de arquivos de maneira diferente.

O nome do arquivo é usado para armazenar metadados porque a) está sempre lá, b) os metadados sempre estiveram presentes no nome do arquivo (pelo menos no uso de extensões de arquivo) ec) o nome do arquivo sofre muito pouca tradução ao mover entre sistemas (distinções entre maiúsculas e minúsculas, limitações do conjunto de caracteres, limitações de caracteres à parte).

Portanto, o nome do arquivo é visível, portátil e gerenciável. Isso não é ruim para armazenar alguns metadados.

Provavelmente, a melhor solução para abordar os metadados gerais do arquivo é usar um repositório de conteúdo , em que o repositório de conteúdo pode ser configurado com o esquema de metadados a ser usado para os arquivos. Em muitos casos, isso é um exagero, mas, IMHO, é o caminho a seguir para o gerenciamento sério de metadados.


0

Minha opinião sobre isso é que você pode ter visto algum código em algum lugar que faz coisas desleixadas ou quebradiças com nomes de arquivos, mas isso não significa que "armazenar metadados nos nomes de arquivos" seja ruim em geral.

Os nomes dos arquivos são metadados - são dados sobre os dados no arquivo, independentemente dos próprios dados do arquivo. De fato, os nomes de arquivos são tão antigos que provavelmente são o exemplo canônico de metadados.

Se você considerar que as extensões de arquivo são apenas a parte final do nome do arquivo, o conceito de nome do arquivo como metadado se torna ainda mais inevitável.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.