Design generico della tabella params

Naviga le tue risposte
0

Abbiamo una tabella parametri generica i cui attributi importanti sono: 

id number auto increment not null
domain varchar (200) not null
classification varchar (200) not null
param_name varchar (200) not null
value CLOB/text
created_by, created_date, updated etc

Qui l'id è univoco per la tabella più a livello funzionale c'è un indice univoco su dominio, classificazione, nome_programma

Il valore è testo di qualsiasi lunghezza in UTF-8. Vogliamo aggiungere BLOB, supporto dati binari. Le scelte sono:

  1. aggiungi una nuova colonna: blob_value BLOB O

  2. aggiungi un campo 'tipo' di varchar2 in questa tabella che può essere nullo o 'B', null di default. Il mezzo nullo o vuoto non è - testo Se B significa suo un blob. In quel caso il valore manterrà un id di una riga della tabella blob. La tabella blob avrà il seguente aspetto:

    numero auto incremento automatico dati BLOB

  3. Lascia la tabella esistente da sola e in una nuova tabella che fa riferimento a questa:  parameter_id numero chiave primaria,  blob di dati, con vincolo FOREIGN KEY (parameter_id) REFERENCES Parametro (id) (suggerimento FrankieTheKneeMan grazie)

Il vantaggio del primo è che un parametro può avere sia un testo che un blob o entrambi.

Il vantaggio del secondo - non è sicuro - > non è necessario mantenere colonne vuote? La tabella corrente ha 30.000 file e ci aspettiamo che cresca fino a 70.000, di cui il 10% necessiterà di dati blob.

Domanda: quale di questi sceglieresti e perché o hai un supplente?

    
posta tgkprog 12.07.2013 - 17:43
fonte

1 risposta

2

È una relazione uno a uno tra Parametri e blob - ogni blob deve avere un parametro, ma non tutti i parametri hanno bisogno di un blob, giusto? 70000 righe non sembrano così tanto, quindi probabilmente aggiungerei un'altra colonna per salvarti il join quando hai bisogno di dati blob (i join possono essere ingannevolmente costosi). Inoltre, sovraccaricare il valore di una colonna in base al valore di un'altra è una ricetta per problemi. Va bene se tu sei l'unica persona che abbia mai intenzione di toccare questi tavoli, e tu non dimentichi mai nulla. Dal momento che sono raramente il caso, consiglierei di non farlo. C'è una falsa economia nel portare la codifica nei tuoi tavoli.

Se sei preoccupato per lo spazio di archiviazione, prova qualcosa di simile per dimensioni - non aggiungere nulla alla tabella dei parametri, e invece rendere la tua chiave primaria sulla tua tabella blob anche una chiave esterna per la tabella dei parametri. In questo modo: 

parameter_id number primary key //ensures uniqueness
data blob
FOREIGN KEY (parameter_id) REFERENCES Parameter(id) //Ensures that it matches a parameter,
    //As well as adding a bit of speed to your select (and the cost of your inserts).
    
risposta data 12.07.2013 - 19:27
fonte

Leggi altre domande sui tag

Formato di file amichevole, solo accenno al controllo della versione: "binario" o "testo"? Come si chiama un'applicazione che non è specificamente legata a una struttura DB