127 messaggi dal 06 giugno 2011
Ciao a tutti,

sono alle prese con un bel po di refactoring in un dominio, sto cercando di normalizzare il db nella 2Nf(seconda forma).

Ho una tabella nel db con circa 400 colonne quindi volevo fare una partizione verticale nel senso suddividere questa mia tabella in due tabelle e relazionarle tramite id.

La mia è una tipica tabella di fatturazione testata e corpo, nel corpo (400+ colonne ) ci sono anche tutti i riferimenti di altri documenti, nel senso se prendo un documento ddt e lo porto in fattura differita nel record del corpo ddt e nel record del corpo della fatt. diff mi riporta i relativi riferimenti di entrambi i documenti.

Quindi adesso senza normalizzazione la mia tabella corpo ha le colonne IdDDt,IdFdv,NumeroDDt,NumeroFdv,DataDDt,DataFdv,etc..

Quindi per ogni riferimento nella tabella Corpo Ci sono le rispettive Colonne(100/150 colonne in piu rispettivamente per ogni tipo di documento che sia ddt, differita,nota credito,buono etc...).

Adesso voglio normalizzare splittando la tabella togliendo tutte le colonne dei riferimenti(NumeroDDt,NumeroFdv,NumeroBuono,etc..)

e metterle in una tabella a parte (RiferimentiDocumenti) , facendo cosi elimino almeno 100/150 colonne (tutte relative ai riferimenti).



Però mi sorge un dubbio a video io ho la necessita di vedere queste informazioni di ogni riferimento(per raggruppamenti,stampe etc..) quindi quando il cliente ricerca un documento devo comunque fare un join per portarmi in una classe DTO tutte queste informazioni.

Ricapitolando:

Stavo Pensando di dividere in due la tabella nel db CorpoDocumento e RiferimentiDocumento e relazionarli tramite un Id

poi crearmi una classe CorpoDocumentoDTO (con tutte le colonne che mi servono a video 400+) quando ricerco la fatture farmi un join per unire le due tabelle del db nella mia classe CorpoDocumentoDTO(tabella temporanea in memoria che non esiste neldb).





Volevo qualche consiglio , se quello che vorrei fare è giusto o ci sono altre soluzioni e sopratutto se per le prestazioni è una buona pratica oppure non cambia nulla visto che poi sono costretto a fre un join e portarmi tutto in una classe in memoria.

Anche perche c'è da considerare il limite massimo di memoria che sql ha...



ps.: sto utilizzando Ef Code First
239 messaggi dal 22 gennaio 2017
Contributi
Il costo di una Join è superiore al costo di un filtro su indice.
La denormalizzazione è un bene che a volte si scontra con l'effettivo risultato.

Se le molte colonne di estrazione vengono filtrate (CLAUSOLA WHERE) solamente dai campi della tabella di dettaglio, non otterrai i benefici sperati.
In uno scenario simile, fa la differenza la tabella delle testate sulla quale è necessario creare gli indici opportuni per poi accedere ai dettagli.

Per uno scenario in cui i documenti fossero divisi in più tabelle (ognuno con la funzione, ad esempio una tabella per DDT, una per altri documenti etc) avresti l'accesso al dato più veloce poichè dividi i dati in tabelle ma dovresti gestirne le conseguenze.


Per aumentare i tempi di lettura, forse, ti conviene creare una campo contenente la natura del documento (DDT, fattura etc) e su di esso gestire una partition function.
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-partition-function-transact-sql
In questo modo avresti un accesso più veloce (avrai N partizioni e non una unica tabella).
127 messaggi dal 06 giugno 2011
facendo un po di ricerca ho letto questo articolo

https://technet.microsoft.com/en-us/library/aa224786(v=sql.80).aspx



dove evidenzia che la normalizzazione non sia sempre la scelta miglriore in base al contesto.

nel mio contesto tutti quei campi mi servono sia mostrarli a video che fare dei raggruppamenti quindi sarei costretto ad effettuare sempre delle join.

Però la tabella ha raggiunto il numero masismo di colonne perche sql mi avvisa
"CorpoFatturaImmediata" è stata creata ma le dimensioni massime delle righe superano il valore massimo consentito, pari a 8060 byte. Le operazioni INSERT o UPDATE eseguite su questa tabella avranno esito negativo se le dimensioni delle righe
Modificato da brux88 il 28 agosto 2017 10.16 -
239 messaggi dal 22 gennaio 2017
Contributi
In questo caso, ti conviene valutare una tabella che contenga le informazioni di dettaglio utilizzate per filtrare i dati o raggrupparli.
In seguito dovresti spezzare le colonne in 2 o più tabelle contenenti le colonne utilizzate per i vari ambiti.
Immagino che ci saranno colonne specifiche per i report e altre per la sola visualizzazione.
Sei costretto a dividere le colonne su più tabelle.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.