Arquitectura de almacenamiento de metadatos de entidad

Question

Estamos creando una solución para el almacenamiento de documentos y para cada documento necesitamos almacenar una gran cantidad de metadatos adicionales para cumplir con las regulaciones locales, que van desde datos básicos como título o descripción hasta fechas de eventos relevantes o reglas de disposición y clasificación .

He visto diferentes tipos de soluciones, pero ninguna me convence:

1. Tablas que crecen en columnas cuando se agrega un nuevo espacio de metadatos (por lo que tienen tantas columnas como metadatos asociados con los documentos)
2. Tablas con muchas columnas genéricas de repuesto. Muy similar a 1. pero las tablas no crecen (menos permisos)
3. Una tabla de identificadores de documentos, claves de metadatos y valores de metadatos.
4. Una tabla con definiciones de metadatos y claves de metadatos en 3. se sustituye por identificadores de metadatos. Utilizamos esta solución en el pasado. Las tablas tienen millones de filas al final.
5. Un campo de texto en la tabla de documentos o tabla asociada que almacena un XML u otra información estructurada con todos los metadatos en pares clave-valor.

Estoy sesgado hacia el número 5, proporcionando un índice de texto completo paralelo (Lucene.Net? Other?) para buscar por metadatos relevantes (no todo tiene que ser '' buscable '').

¿Alguna sugerencia? ¿Experiencias similares?

Answer 1

Tabla 1: Información del documento (PK es ID del documento)

Tabla 2: definiciones de metadatos (PK es ID de definición de metadatos)

Tabla 3: ID del documento, ID de definición de metadatos, valor de metadatos

El mayor inconveniente de esto es que tendrías que tener un solo tipo (varchar, presumiblemente), o tendrías que tener n columnas (donde n es la cantidad de tipos de datos que estás dispuesto a almacenar ) y use una columna en la tabla de definiciones de metadatos para identificar de qué columna de la tabla 3 extraer el valor.

Mis opiniones sobre las 5 soluciones enumeradas:

1. Cultivar tablas es una molestia y podría causar problemas en el futuro (especialmente si desea / necesita un valor de metadatos no anulables).
2. odio 'columnas genéricas de repuesto' con pasión (a pesar de que son populares).
3. Cerrar, pero esto limita su flexibilidad de metadatos aún más que mi solución. Si sus claves y valores de metadatos son bastante básicos, podría funcionar.
4. No estoy realmente seguro de lo que quieres decir con esto: ¿es lo mismo que propongo o algo más?
5. No me gusta almacenar XML estructurado en un RDBMS: se pierde la mayor parte del poder del RDBMS al hacer esto en mi humilde opinión.

Ese es mi pensamiento: nunca he diseñado un sistema como este, pero he tratado con sistemas comerciales que han utilizado varios de estos esquemas.

Answer 2

¿Por qué no usar CouchDB ? Está diseñado precisamente para abordar este tipo de requisitos.

Si esa no es una opción, considere usar Lua o JSon (según su opción # 5) como descriptor de metadatos.

Answer 3

Tal vez pueda echar un vistazo a JCR (Java Repositorio de contenido). JCR es un estándar para el repositorio de contenido que captura los requisitos comunes de la administración de contenido, como el control de versiones, la búsqueda de texto completo y la edición. También proporciona un nivel de resumen en el almacenamiento de contenido, lo que significa que puede usar una API para colocar contenido en cualquier tipo de sistema de almacenamiento como base de datos, archivo xml, etc. Por supuesto, puede agregar metadatos a su documento agregando algunas propiedades a nodo de documento con API JCR. No tiene que preocuparse por cómo se almacenarán el documento y los metadatos. JCR se encargará de ello. Jackrabbit es la implementación de referencia de JCR. Pruébalo.