Progettazione di database errata - La mia tabella è troppo grande?

Question

Ho un database mal progettato. Una delle tabelle più importanti ha oltre 11.000 voci. Vorremmo espandere il nostro sistema e mi chiedo se questa tabella sia cresciuta fino a 5 volte la sua dimensione, sarebbe un problema? Ha una dimensione di 15360 kB ... se questo è importante.

---

Sto usando phpMyAdmin, il server è un box Fedora Linux (niente di speciale), Il carico è leggero. Memorizza praticamente tutto ciò che utilizza il nostro sistema.

Answer 1

Comprendo che sei preoccupato se aumenti il ??numero di record a circa 55.000 nel "tuo database mal progettato" influenzerà le prestazioni.

Se ora il tuo sistema funziona come previsto, penso che dovresti andare bene anche con 50.000 record, a meno che tu non abbia già qualche leggero problema di prestazioni.

Poiché la maggior parte delle persone ha menzionato record da 50k è un numero molto piccolo in relazione alle dimensioni della tabella del database e anche con un database non normalizzato non dovrebbero esserci problemi di prestazioni.

Se stai pianificando di espandere la funzionalità del tuo sistema, allora forse sarebbe un buon momento per guardare anche al design del database, altrimenti dovrebbe essere ragionevolmente sicuro lasciarlo così com'è.

Answer 2

Quale DBMS? Quale server? Quale carico? Quale applicazione?

Inoltre: 11.000 dischi non sono nulla, davvero. Anche in MS Access. : -)

EDIT: Quindi suppongo che tu usi un MySQL abbastanza recente con le tabelle MyISAM. In teoria, puoi andare avanti e riempire la tabella in milioni di record. A seconda di come lavori con loro (molti join / o, molte query / aggiornamenti / eliminazioni / o no), non devi fare nulla di speciale. Metti un indice adeguato sul tavolo e dovresti stare bene.

Answer 3

Non credo che tu stia fornendo informazioni sufficienti a qualcuno per dare una risposta. Perché è mal progettato? Non è normalizzato? Non hai indici? Che DB è? Su quale sistema operativo è in esecuzione? Quanto tempo ci vuole ora per interrogare un record dalla tabella in questione?

Answer 4

11k voci non sono così tante. Anche 50K non è grande.

Mettere gli indici sul tavolo (ottimizzato per le query che verranno eseguite su di esso) consentirà buone prestazioni per importi molto più grandi di quello che si sta immaginando.

Se il design è abbastanza scarso, potresti esaminare il costo della riprogettazione.

Answer 5

Cosa intendi con un "database mal progettato"?

Se è progettato in modo errato, riprogettarlo, trascinare le informazioni dalle tabelle correnti e popolare quella nuova.

Se sei preoccupato per le prestazioni, 11000 voci non sono grandi. Un database da 15 megabyte è estremamente piccolo, secondo gli standard db.

Answer 6

La dimensione di una tabella non è molto importante. Il design della chiave, degli indici e delle relazioni ha molto più a che fare con la qualità del design che con la dimensione dei dati in esso contenuti. Ci sono ovviamente avvertenze a questo; ma l'ottimizzazione delle dimensioni di una tabella è quasi l'ultima cosa che faccio quando lavoro su un problema di prestazioni o di progettazione.

Potresti voler spiegare di più sul perché pensi che questo sia un database mal progettato e cosa puoi fare (facilmente) per correggere i problemi. Insieme a questo dovresti dettagliare il tipo di DBMS e quale sia l'utilizzo (app web, app personalizzata, rapporti, ecc.).

Answer 7

15 MB è nulla. Anche 11k righe. Ho database con 2+ GB di dati, con alcune tabelle che contengono oltre 1 milione di righe e ritengo che si tratti di un punto tra le dimensioni piccole e medie.

Answer 8

In realtà non hai fornito alcuna prova a sostegno della tua affermazione che si tratta di un database mal progettato. Cosa lo rende mal progettato? la tabella ha 876 colonne? Le colonne sono denominate Col1, Col2, Col3 ...? Utilizza un float e un datetime come chiave primaria composita? È scarsamente normalizzato? L'unica cosa che sappiamo è il conteggio dei record.

Answer 9

I record 11K non sono in genere nulla in termini di database.

Cos'altro ti fa pensare che il database sia mal progettato a parte il numero di record in una tabella?

Answer 10

Devi fornire molte più informazioni sulla struttura della tabella.

In generale, 15.000 righe in una tabella sarebbero considerate piccole, in realtà così piccole, che alcuni designer potrebbero non preoccuparsi nemmeno di indicizzarle.

Answer 11

Una cattiva fondazione sarà il tuo errore più costoso. Se la tabella è importante, è necessario decidere quanto sia importante correggerla. La quantità di righe in una tabella influisce solo sulla velocità con cui è possibile estrarre elementi da essa. Ma se hai una cattiva progettazione del database per cominciare, le tue mani saranno legate in determinati punti lungo la strada.

Answer 12

Se si parla di SQL Server 2005, consultare il profiler di SQL Server e utilizzare la procedura guidata Sintonia indice.

In alcuni database è inoltre supportato il blocco delle tabelle in memoria se si desiderano prestazioni aggiuntive.

Answer 13

Ciò che comprende un record può avere più importanza di quanti record ci sono in una tabella.

Dove lavoro abbiamo database con numerose tabelle con conteggi record nelle decine di migliaia o centinaia di migliaia. I nostri database sono considerati piccoli, per la maggior parte.

Answer 14

Se hai intenzione di espandere il tuo sistema, ora è il momento di riprogettare se necessario. È molto meno doloroso riprogettare quando hai 11.000 dischi rispetto a quando ne hai 10 milioni. Tuttavia, nulla di ciò che hai detto mi indica che devi riprogettare. Non c'è nulla di intrinsecamente sbagliato nell'avere join (in effetti un database ben progettato dovrebbe averli). Pubblica alcuni dettagli sulla struttura e possiamo aiutarti a decidere se è necessario riprogettare.

È possibile che il problema sia che tu e i tuoi colleghi non avete esperienza nell'accesso al database e non sapete come interrogarli in modo efficace e semplice. Oppure il problema potrebbe essere che il design è cattivo, senza dettagli sulla struttura, è difficile da dire.