Diseño de la base de datos - Consejo - ¿Cómo lo harías?

Question

Tengo que agregar algo de funcionalidad a un sistema que ya es un desastre y no quiero empeorar las cosas. Esta tienda pone muy poco valor en el diseño adecuado, pero lo hago buscando un compromiso.

Quieren agregar la capacidad de agregar archivos adjuntos a varias entidades en la base de datos, pero los archivos se almacenarían en un sistema de archivos. Las entidades que les gustaría adjuntar archivos (uno a muchos) son, y quieren que cada archivo adjunto se tenga en cuenta en la base de datos (el nombre de archivo del puntero con root_mount_point un parámetro dinámico. Cómo lo mantendré en sincronización es mi siguiente pesadilla. Pero yo '' M desgarrado sobre qué usar para una "muchos" tabla para una a muchos archivos adjuntos para un cliente, cuenta, proveedor o factura.

create table client {
  client_id      char(11)   not null,
  ...
}

create table account {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  ...
}

create table vendor {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
    ...
}

create table invoice {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
  invoice_number char(22)   not null,
  invoice_date   datetime   not null (yes this is part of PK)
  ...
}

Cada uno de estos es uno a muchos a medida que avanza.

Estoy pensando en hacer algo como esto para una tabla "file_attachment" que puede ser una tabla para cualquiera de las cuatro entidades, dependiendo de qué columnas sean nulas. Si la factura COLS es nula, el accesorio es para proveedores, etc.

create table NEW_ENTITY_ATTACHMENT {
   attach_id           char(11)   not null   (dummy key, but keeping their char 11 standard),
   attach_status_cd    char(1)    not null,   ( "A"ctive or "D"eleted ) ,etc.
   attach_status_date  datetime   not null,  (they want complete history, soft deletes, and restores)
   client_id           char(11)   not null,
   account_number      char(22),
   vendor_number       char(15),
   invoice_number      char(22),
   invoice_date        datetime,
   attachment_filename char(blah blah),
   ..
   .. 
   blah
}

Por lo tanto, se requieren las primeras tres columnas, se requiere Client_ID y la cuenta, el proveedor, la factura opcional dependiendo del nivel se almacena el archivo adjunto.

¿Estoy muy lejos de mi pensamiento aquí? atornillado.

No hago muchas preguntas, pero aprecio enormemente ninguna sugerencia. Tenga en cuenta que este cliente solo quiere que se realice un proyecto de uno a dos días, incluido el modelo de datos, la GUI y el backend. Es Sybase ASE15 si importa.

Gracias por adelantado. Riñonal

Answer 1

Dadas las estructuras clave de las otras tablas, tiene sentido poner todos sus accesorios en una tabla. Por ejemplo, podrá consultar todos los archivos adjuntos que pertenecen a un cliente (en todos los niveles) seleccionando Just Client_ID, y archivos adjuntos que pertenecen a un cliente (en ese nivel) seleccionando en Client_ID y Account_Number Is Null .

El único problema que veo es la clave para su nueva tabla:
Usar una fecha como parte de una clave (adjunto_status_date) me hace sentir incómodo (y obviamente también te incomoda en función de tu comentario sobre Invoice_Date).

¿Va a ser único? Si no es así, incluso con adjuntar_status_date como parte de su clave, es posible que no obtenga una clave única. Si va a ser único (¿un GUID quizás?) Entonces, ¿tener adjunte_status_date como parte de la clave no parece necesaria, especialmente porque no parece que se vincule con este campo? ¿Quizás debería ser indexado?

Answer 2

Parece que te has perdido algunos pasos de normalización. Debe ver si la columna introducida en cada niño identifica de manera única la entidad. Luego use una clave extranjera para el padre. El proveedor es típicamente una mesa fuerte y no el hijo de otra tabla.

La tabla de fijación probablemente debería ser una tabla independiente. Agregue un accesorio anulable_id a cada entidad que pueda tener un archivo adjunto. Si la entidad puede tener múltiples archivos adjuntos, use una tabla de relación de muchos a muchos en lugar de una columna.