Pro / Cont al layout della tabella del database in relazione alla manutenzione e all'estendibilità

Naviga le tue risposte
1

Layout pseudo-classe di base sotto ... 

class Location(): # Class containing information about a location.
    id
    address_one

class CustomerLocation(Location):
    customer_id
    account_rep 

class VendorLocation(Location):
   vendor_id
   drop_ship_cut_off_time

Supponiamo che tu abbia posizioni che verranno utilizzate per memorizzare informazioni sulla posizione per clienti e fornitori.

Quali sarebbero le pro / contro delle tre opzioni in relazione alla manutenzione e all'estensibilità dell'applicazione ...

  1. Una grande tabella contenente tutti i campi.
  2. Una tabella di grandi dimensioni contenente tutti i campi comuni con tabelle correlate contenenti informazioni specializzate sui record di tabelle di grandi dimensioni.
  3. Molte piccole tabelle contenenti tutti i campi relativi a usi specifici. Tabella dei clienti tabella dei fornitori senza utilizzare una "tabella principale" per i campi comuni.
posta Ominus 06.02.2012 - 22:20
fonte

2 risposte

2

Un buon design del database implica che si normalizzi adeguatamente il database. È possibile generalizzare la posizione, assumendo che si desideri registrare diverse posizioni per un cliente o un fornitore, è possibile eseguire questa operazione:

  • Cliente (0,1, più) Posizione

  • Fornitore (0,1, più) Posizione

  • Posizione

Non vedo perché hai 2 classi separate CustomerLocation, VendorLocation.

Potresti andare oltre nel generalizzare Vendor e Cliente come Party con Vendor e Cliente che ereditano dal tipo astratto Party .

Quanto sopra è valido a meno che:

  • Un cliente può essere un venditore o vice-versa e / o

  • La stessa posizione è l'indirizzo di più di un fornitore o cliente

Modifica

Non è possibile utilizzare Party con inerenza come suggerito sopra (prima del tuo commento) poiché il tuo commento implica che i clienti possono essere venditori e fornitori possono essere clienti. Quindi, in effetti, hai solo una parte con un tipo di party non-esadecimale che può essere rappresentato da 2 colonne booleane: IsCustomer e IsVendor (questo può essere complicato creando una tabella separata per registrare quando lo stato è acquisito).

Ora, la relazione tra un partito e la posizione è molti-a-molti.

La tabella di intersezione risultante dalla relazione molti-a-molti può contenere colonne non utilizzate.

Nel progettare una struttura di database non complicare la progettazione perché potrebbero esserci colonne non utilizzate. Alcune applicazioni ERP hanno 100s di colonne in una tabella e solo poche vengono mai utilizzate! Assicurati di specificare che le colonne inutilizzate siano Varchar e scegli saggiamente l'abilità nulla.

    
risposta data 06.02.2012 - 22:31
fonte
0

Vai all'opzione # 2. Non ci sono colonne sprecate sedute lì con valori null. E non vi è alcuna duplicazione di colonne in più tabelle. Hai esattamente ciò di cui hai bisogno. Molti sistemi reali usano l'opzione # 2.

È utilizzato in molti software di contabilità. Avrai una tabella di transazione principale. Se la transazione è di tipo "speciale" con campi aggiuntivi, avrà un record in un'altra tabella (relazione 1 a 1) per memorizzare i campi aggiuntivi.

    
risposta data 07.02.2012 - 01:33
fonte

Leggi altre domande sui tag

Ottenere e mantenere dati da un gran numero di fonti sul web [chiuso] Buone risorse per argomenti C ++ avanzati? [chiuso]