Come si normalizza un database per ridurre le voci duplicate?

Question

Come si normalizza un database per ridurre le voci duplicate?

#1 da (1 voti)

0

Sto progettando un sistema di database + un'applicazione che si occupa di oggetti di tubature che fanno parte di una rete di rete più grande. Ci sono circa 1000-5000 pipe per ogni rete. Supponiamo che ogni tubo possa avere 2 stati (pulito, sporco).

L'applicazione è in grado di modificare lo stato del tubo dopo che un intervento di manutenzione è stato eseguito su quella conduttura. Ogni lavoro di manutenzione ha un ID e molte altre informazioni dietro di esso. Lo stesso vale per i tubi.

Il mio design per questo problema è il seguente:

table: pipe_status

id     maintenance_id         pipe_id        status
1      1                      1              clean
2      1                      2              clean
3      1                      3              dirty
4      1                      4              dirty
...
1000   1                      1000           dirty
1001   2                      1              clean
1002   2                      2              clean
1003   2                      3              dirty
1004   2                      4              clean
....
2000   2                      2000           dirty

Quindi, per ogni lavoro di manutenzione, ogni singola pipa dovrebbe avere un attributo di stato, a seconda che siano stati interessati da questo particolare lavoro di manutenzione o meno. Ciò significa che per ogni lavoro di manutenzione ci sono tante voci di stato quante sono le pipe, con un conseguente aumento della quantità di dati.

Esempio: 20+ griglie con tubi 1000-5000. Al momento sono necessari più di 500 lavori di manutenzione per rete e in crescita, con risultati di 10-50 milioni di voci in questa tabella.

C'è un modo migliore per implementare questo problema in un database? È importante notare che lo stato di ciascuna pipe viene visualizzato nell'applicazione, quindi anche se un intervento di manutenzione interessa solo 5 pipe, gli altri 995 vengono ancora visualizzati nell'app. In questa applicazione l'utente può selezionare un lavoro di manutenzione specifico e vedere i tubi corrispondenti e il loro stato.

database normalization

posta akgis 18.10.2018 - 10:22

fonte

1 risposta

Leggi altre domande sui tag database normalization

Eseguendo operazioni su entità o dto Database contenitore microservizi

score 1 · Answer 1

Sulla base della mia comprensione del problema, si potrebbe vedere che questa è una tipica associazione M-M tra un tubo e un lavoro di manutenzione.

Ogni pipe viene mantenuta su zero, uno o più lavori di manutenzione.
Ogni lavoro di manutenzione riguarda una o più pipe.

Ciò richiede la creazione di una tabella intermedia per la risoluzione dell'associazione M-M (a volte chiamata tabella di giunzione). Questa tabella include tra gli altri attributi:

CleanedPipesTable

pipeID_FK

JobID_FK

JobFinishTimeStamp

Dici che "for every maintenance job, each individual pipe should have a status attribute" Questo potrebbe significare che dopo ogni lavoro alcuni dei tubi saranno puliti, alcuni rimarranno sporchi. Invece di inserire lo stato di ogni pipe con ogni lavoro (che è logico ma sarà molto inefficiente da elaborare), potremmo decidere di limitare l'ambito del contenuto della tabella solo alle pipe "pulite". Di conseguenza, non è necessario memorizzare il valore dello stato in ogni riga poiché sarebbe "pulito" per tutte le righe. Gli indici appropriati devono essere creati sulle colonne ID e timestamp, naturalmente.

Ciò consentirà di risparmiare tempo nell'elaborazione degli inserimenti, tuttavia, influirà sull'elaborazione dell'indagine.

so even if a maintenance job only affects 5 pipes, the other 995 are still shown in the app.

In questo caso, dovrai selezionare gli ID delle pipe pulite, impostare lo stato di quelli da pulire e selezionare il resto delle pipe (tutte tranne quelle filtrate) e assegnare loro uno stato "sporco".

Questo dovrebbe essere molto veloce perché, si userà un indice per ottenere le pipe interessate, e si accede all'intera tabella di pipe in sequenza (magari ordinata da pipeID) che dovrebbe essere anche molto veloce. L'elaborazione dell'intersezione potrebbe avvenire tramite SQL o tramite logica di programmazione. In entrambi i casi, non dovrebbe essere un grosso problema.

Per completare la vista logica qui, il programma dovrebbe fare un'affermazione secondo cui ogni pipe che non appare sulla nuova tabella ha lo stato di "dirty".

In generale, possiamo solo giudicare se questa modalità è buona o cattiva sulla base non solo delle sue prestazioni, ma anche della sua capacità di rispondere a tutte le richieste attese. Ad esempio, cosa succede se si desidera conoscere lo stato di una data pipe tra 2 date o elencare lo stato di ogni pipe del sistema tra diversi mesi ... ecc. Tutte le query di questo tipo devono essere prese in considerazione prima di decidere il modello da utilizzare, perché i dati sono in rapida crescita.

Suppongo che sulla base delle informazioni limitate a condizione che questo approccio sia migliore dell'approccio in cui ogni tubo deve essere inserito con uno stato per ogni lavoro di manutenzione, poiché questo approccio limiterà il numero di righe e presumo che potrebbe eseguire meglio.

Forse testare l'approccio fornirà una prova venduta, un test dovrebbe essere facile da configurare per questo caso.

Buona fortuna.