Quando hai troppi tavoli?

Due dei miei colleghi e io stiamo costruendo un sistema per fare ogni tipo di idrologia e materiale correlato. Ha molti requisiti e un buon numero di tavoli.Quando hai troppi tavoli?

Stiamo gestendo tutti i tipi di campionamento che è fatto in questo ambito (idrologia) e stiamo cercando di capire un modo per farlo in modo meno doloroso.

A volte abbiamo bisogno di ottenere tutto quel campionamento insieme e sto iniziando a pensare che stiamo complicando eccessivamente la progettazione del nostro database.

Come o quando sapete di sovrascrivere un database? Ovviamente stiamo prendendo in considerazione un sacco di regole del modulo normale e altre buone pratiche, ma quando è opportuno eliminare una di queste regole, ad es. non normalizzare qualcosa?

Quali sono le vostre opinioni in merito?

fonte

2010-02-04 George Silva

"Normalizza fino a quando fa male, denormalizza fino a quando non funziona." : http://www.codinghorror.com/blog/archives/001152.html – Fionnuala

Stai usando ORM o SQL diretto per accedervi? Ho trovato che l'uso di ORM, in particolare per mantenere informazioni che possono essere gerarchiche e che è rappresentato in runtime come una gerarchia di classi, si presta a un gran numero di tabelle. Se dovessi manipolarlo manualmente, sarebbe orribile. – Uri

Risposta breve

Non si può, preoccuparsi di qualcos'altro.

risposta Lunghi

Questo suona come l'ennesima forma di premature optimization. (YAFPO?)

È necessario progettare lo schema utilizzando third normal form (3NF). Una volta progettato, è necessario popolare le tabelle con i dati e iniziare la creazione di profili.

Se una query particolare è considerata troppo costosa, è necessario esaminare denormalization caso per caso.

risposta tecnica (per i nitpickers che inevitabilmente opporsi a: "non si può")

Si raggiunge un limite ad un certo punto in base alla scelta di RDBMS e/o motore di archiviazione. Probabilmente i massimali saranno il consumo di memoria o i descrittori di file aperti.

fonte

2010-02-04 23:27:52 hobodave

Le query costose possono essere attaccate con diversi mezzi: denormalizzazione, visualizzazioni, visualizzazioni materializzate, controllo degli indici, verifica se gli indici si trovano in un tablespace diverso, ... – Alfabravo

@Alfabravo: sei corretto. Non intendevo comunicare che la denormalizzazione era l'unica opzione disponibile. Stavo invece limitando la portata della mia risposta per affrontare la paura delle "molte tavole". – hobodave

Giusto, anche tu sei corretto :) BTW: per il nostro amico impaurito, in questo momento sto lavorando ad alcuni bizzarri EJB fatti da un gruppo di scimmie che usano circa ... fammi fare i conti .. 1600 tavoli. Quindi, compra un pallone pieno di vitamine e uccidi! (non letteralmente) – Alfabravo

Abbiamo un sistema con letteralmente centinaia di tabelle: non è un grosso problema, è solo che molte cose diverse sono memorizzate nel database.

fonte

2010-02-04 23:27:06 Justin

Humn, ma per quanto riguarda la complessità? Stiamo lavorando con molte tabelle correlate, ad esempio: abbiamo una tabella dei punti di monitoraggio, una tabella degli strumenti (1: m con punto di monitoraggio) e n tabelle che fanno riferimento agli strumenti. Questo tipo di cose si ripete sul progetto. Lo stiamo facendo male? C'è un modo migliore? Si prega di notare che questi non vengono ripetuti. –

@George: dovresti chiedere questo genere di cose in un'altra domanda; non in un commento. Mostraci il tuo schema e chiedi feedback. – hobodave

Ma per favore, solo poche tabelle –

Abbiamo anche un sacco di tabelle nel nostro sistema. Ciò che abbiamo fatto è stato normalizzare il database a un buon punto, quindi abbiamo creato alcune viste che racchiudono le più comuni esigenze di utilizzo del nostro sistema. Qualcosa del genere potrebbe aiutarti anche tu.