1. Inicio
  2. Pregunta y respuesta
  3. ¿La mejor manera de diseñar este escenario de base de datos?

¿La mejor manera de diseñar este escenario de base de datos?

2010-08-04 17 views
6

El requisito es almacenar archivos adjuntos para diferentes tipos de entidades.¿La mejor manera de diseñar este escenario de base de datos?

Digamos que tenemos 3 tipos de entidades Empresa, Departamento y Empleado. Cada uno puede tener múltiples archivos adjuntos (documentos).

¿Cuál es la mejor manera de manejar esto?

Solución 1:

mesa Compañía

  • CompanyID

mesa Departamento

  • DeptId

Empleado mesa

  • EmployeeId

mesa AttchmentType

  • TypeId
  • Tipos (empresa, departamento, empleado)

tabla Adjuntos

  • de archivo adjunto
  • TypeId (mapas de tipo de archivo adjunto)
  • entityId (mapas a CompanyID/DeptId/EmployeeId)

Pros: Puedo añadir nuevos tipos de entidades fácilmente en el futuro

Contras: En este caso, no puedo mantener la relación de clave externa mantenida entre las entidades y los archivos adjuntos.

Solución 2:

mesa Compañía

  • CompanyID

mesa Departamento

  • DeptId

Empleado tabla

  • EmployeeId

tabla CompanyAttachments

  • de archivo adjunto
  • CompanyID (FK)

tabla DeptAttachments

  • de archivo adjunto
  • DeptId (FK) tabla

EmployeeAttachments

  • de archivo adjunto
  • EmployeeId (FK)

Pros: la integridad de clave externa

Contras: Para añadir nueva entidad Necesito tener nueva tabla de datos adjuntos por separado.

Entonces, ¿cuál es la mejor manera de ir con el supuesto de que puede ser necesario añadir nuevas entidades en el futuro?

Edición 1:

Gracias por su respuesta chicos.

Si yo quiero ir con la solución 2, veo que crea una nueva columna en la tabla de archivos adjuntos más fácil en lugar de crear nuevas tablas de fijación para cada entidad sólo para asignarlos? algo como,

mesa Compañía

  • CompanyID

mesa Departamento

  • DeptId

tabla de empleados

  • EMPLOYEEID

Adjuntos

  • de archivo adjunto
  • CompanyID (FK)
  • EmployeeId (FK)
  • DepartmentID (FK)

¿Me falta algo aquí?

Fuente

2010-08-04 puzzled

+0

¿Has mirado en NoSQL basada en documentos (es decir, CouchDB) bases de datos? – JNK

Respuesta

3

Voto la solución 2 porque de esta manera usted puede imponer la integridad referencial de manera adecuada. Además, puede agregar fácilmente (si es necesario) campos para archivos adjuntos especiales (por ejemplo, EmployeeAttachments podría tener un campo de bit "PersonalPicture" o similar)

Fuente

2010-08-04 17:14:27

+1

+1, 'agregar campos para archivos adjuntos especiales' los usuarios eventualmente querrán esto. –

5

Definitivamente iré con la solución n. ° 2. Tu único profesional para la solución n. ° 1 no es realmente un profesional. Si agrega una nueva entidad, tendrá que agregar una nueva tabla para esa entidad y ya estará agregando o cambiando el código existente para manejarla. Debería poder hacer algunos objetos genéricos que manejen el patrón para que el código duplicado no sea un problema.

Fuente

2010-08-04 17:15:03

+1

La integridad de datos impuesta a través de FK supera cada vez menos el tiempo de mantenimiento (especialmente un tipo de mantenimiento que nunca será necesario). – HLGEM

+1

+1, la solución n.º 1 podría tener probelmas, lo que sucede cuando tiene el mismo valor de clave en CompanyId/DeptId/EmployeeId, como si usa valores de identidad/incremento automático. –

0

Otras cosas a considerar:

¿Vas a tener que enrollar los archivos adjuntos? es decir, los archivos adjuntos de un empleado están asociados con su departamento y su empresa? si esta es una consulta frecuente, una sola tabla de adjuntos y una opción de tabla de búsqueda de entidad separada y fuertemente indexada pueden proporcionar un mejor rendimiento de consulta.

Además, ¿los archivos adjuntos van a ser muchos y/o lo suficientemente grandes como para colocar esas tablas en un dispositivo diferente u otro sistema de almacenamiento (es decir, punteros del sistema de archivos)? La administración es un problema y también un rendimiento.

Fuente

2010-08-04 18:30:06 Rawheiser

+0

No. Los archivos adjuntos solo están relacionados con su entidad correspondiente y no están enrollados. La tabla de archivos adjuntos simplemente almacena la ruta de archivo/url. Los archivos reales se almacenan en el servidor de archivos. – puzzled

+0

De acuerdo, las tablas separadas son el camino a seguir. Creo que debe tener una vista de unión de todos los nombres de archivo o rutas, para poder auditar los datos. es decir, si alguien accidentalmente borró el archivo, etc. También, si se necesita archivarlo, piense cómo manejaría los contenidos comprimidos y moviéndose a dispositivos diferentes (es decir, de un disco al otro, a un DVD, etc.) – Rawheiser

2

Espero que esto se explica por sí mismo.

attachment_model_v1

Fuente

2010-08-04 21:28:37

+1

Gracias Damir . Espero que esta sea la solución óptima si empezamos desde cero. Pero desafortunadamente en mi caso, las entidades ya están en uso, con sus propios Ids en su lugar. – puzzled

Cuestiones relacionadas

 Cuestiones relacionadas