Design del database - Consigli - Come lo faresti?

Question

Devo aggiungere alcune funzionalità a un sistema che è già un disastro e non voglio peggiorare le cose. Questo negozio attribuisce un valore molto scarso al design adeguato, ma lo faccio a cercare un compromesso.

Vogliono aggiungere la possibilità di aggiungere allegati di file a varie entità nel database ma i file verrebbero archiviati su un file system. Le entità che vorrebbero allegare file (una a molti) lo sono e vogliono che ogni allegato sia spiegato nel database (nome file puntatore con root_mount_point un parametro dinamico. Come lo terrò in sincronizzazione è il mio prossimo incubo. Ma io ' M lacerato su cosa utilizzare per una tabella "molte" per l'uno a molti allegati per un cliente, un account, un fornitore o una fattura.

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)
  ...
}

Ognuno di questi è uno a molti mentre ti abbassi.

Sto pensando di fare qualcosa del genere per una tabella "file_attachment" che può essere una tabella per una delle quattro entità, a seconda delle colonne nulle. Se le fatture sono nulle, l'allegato è al venditore, ecc.

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
}

Pertanto sono richieste le prime tre colonne, client_id richieste e l'account, fornitore, fattura facoltativo a seconda del livello dell'allegato memorizzato.

Sono molto lontano dal mio pensiero qui, dovrebbe esserci una tabella per ogni entità (ad es. Allegato cliente, allegato di account, allegato del fornitore, allegato alla fattura? Se questa è la risposta che non vogliono sentirlo comunque, quindi lo sono avvitato.

Non faccio molte domande, ma apprezzo molto qualsiasi suggerimento. Tieni presente che questo cliente lo vuole solo, lo considera un progetto da 1 a due giorni tra cui modello di dati, GUI e backend. È Sybase ase15 se è importante.

Grazie in anticipo. R

Answer 1

Date le strutture chiave delle altre tabelle, ha senso mettere tutti gli allegati in una tabella. Ad esempio, sarai in grado di interrogare tutti gli allegati che appartengono a un client (a tutti i livelli) selezionando solo client_id e allegati che appartengono a un client (a quel livello) selezionando su client_id e account_number è null .

L'unico problema che vedo è la chiave per la tua nuova tabella:
L'uso di una data come parte di una chiave (allegato_status_date) mi mette a disagio (e ovviamente ti mette a disagio in base al tuo commento su Invoice_date).

L'Allegato_id sarà unico? In caso contrario, anche con ANKE_STATUS_DATE come parte della chiave potresti non ottenere una chiave univoca. Se sarà unico (forse un GUID?), Avere Anega_Status_Date come parte della chiave non sembra necessario soprattutto perché non sembra che ti collegherai a questo campo. Forse dovrebbe essere solo indicizzato?

Answer 2

Sembra che tu abbia perso alcuni passaggi di normalizzazione. Dovresti guardare se la colonna introdotta su ciascun bambino identifica in modo univoco l'entità. Quindi utilizzare una chiave esterna per il genitore. Il venditore è in genere un tavolo forte e non il figlio di un altro tavolo.

La tabella di allegato dovrebbe probabilmente essere una tabella autonoma. Aggiungi un allegato nullo a ciascuna entità che può avere un allegato. Se l'entità può avere più allegati, utilizzare una tabella di relazioni da molti a molti invece di una colonna.