Entidade arquitetura de armazenamento de metadados

Question

Estamos construindo uma solução para armazenamento de documentos e para cada documento que precisamos para armazenar uma grande quantidade de metadados extra com ele para cumprir com os regulamentos locais, que vão desde dados básicos, como título ou descrição de datas de eventos relevantes ou disposição e regras de classificação .

Eu vi diferentes tipos de soluções, mas nenhum me convence:

1. As tabelas que crescem em colunas quando um novo slot de metadados é adicionado (para que eles tenham as colunas de metadados associados aos documentos)
2. Tabelas com um monte de colunas genéricos peças. Muito semelhante a 1. mas as tabelas não crescem (menos permissões)
3. Uma tabela de IDs de documentos, chaves de metadados e valores de metadados.
4. Uma tabela com definições de metadados e chaves de metadados em 3. são substituídos por ids de metadados. Usamos essa solução no passado. As mesas têm milhões de linhas no final.
5. Um campo de texto na tabela do documento ou tabela associada que armazena um XML ou outras informações estruturado com todos os metadados em pares chave-valor.

Estou inclinado para o número 5, proporcionando um índice de texto completo em paralelo (Lucene.Net? Outro?) Para procurar por metadados relevantes (não tudo tem que ser "pesquisável").

Qualquer sugestão? Experiências semelhantes?

Answer 1

Tabela 1: Informações do Documento (PK é ID documento)

Tabela 2: definições de metadados (PK é metadados ID definição)

Tabela 3: Documento de identidade, Metadados defintion ID, valor de metadados

A maior desvantagem para isso é que você quer tem que ter um único tipo (varchar, presumivelmente), ou você teria que ter colunas n (onde n é o número de tipos de dados você está disposto a loja ), e utilizar uma coluna na tabela de definições de metadados para identificar qual coluna na tabela 3 para puxar o valor de.

As minhas opiniões sobre as 5 soluções listados:

1. Crescimento tabelas é uma dor, e poderia causar problemas para baixo da linha (especialmente se você quer / precisa de um valor de metadados não-nulo).
2. I ódio 'colunas genéricos peças' com uma paixão (embora eles são populares).
3. Fechar, mas isso limita a sua flexibilidade metadados ainda mais do que a minha solução. Se suas chaves de metadados e valores são bastante básico, ele poderia funcionar.
4. Eu não tenho certeza do que você quer dizer com este - é o mesmo que eu estou propondo, ou qualquer outra coisa
?
5. eu não gosto de armazenar XML estruturado em um RDBMS - você perde a maior parte do poder do RDBMS, fazendo isso IMHO
.

É meus pensamentos -. Eu nunca projetou um sistema como este, mas eu tenho lidado com sistemas comerciais que usaram vários desses esquemas

Answer 2

Por que não usar CouchDB ? Sua concebido precisamente para resolver este tipo de exigência.

Se isso não é uma opção, considere o uso Lua ou JSON (por sua opção # 5) como o descritor de meta-dados.

Answer 3

Talvez você pode dar uma olhada em JCR (Java Repositório de conteúdo). JCR é um padrão para repositório de conteúdo que captura os requisitos comuns de gerenciamento de conteúdo como versionamento, pesquisa de texto completo e editar. Também fornece um nível de resumo sobre o armazenamento de conteúdo, o que significa que você pode usar uma API para colocar conteúdo em qualquer tipo de sistema de armazenamento como banco de dados, arquivo XML, etc. Claro que você pode adicionar metadados ao seu documento, adicionando algumas propriedades para nó de documento com JCR API. Você não tem que se preocupar com a forma como o documento e os metadados serão armazenados. JCR vai cuidar dela. Lebre é a implementação de referência de JCR. Tenha uma tentativa.