Mysql
 sql >> Database >  >> RDS >> Mysql

singola tabella fissa con più colonne rispetto a tabelle astratte flessibili

Alcuni problemi devono essere chiariti e risolti prima possiamo avviare una discussione ragionevole.

Risoluzione dei prerequisiti

  1. Etichette
    In una professione che richiede precisione, è importante utilizzare etichette precise, per evitare confusione e in modo da poter comunicare senza dover utilizzare descrizioni e qualificatori prolissi.

    Ciò che hai pubblicato come FixedTables è non normalizzato . Abbastanza giusto, potrebbe essere un tentativo di terza forma normale, ma in realtà è un file flat, non normalizzato (non "denormalizzato). Quello che hai pubblicato come AbstractTables è, per essere precisi, Entity-Attribute-Value , che è quasi, ma non del tutto, la sesta forma normale, ed è quindi più normalizzata di 3NF. Supponendo che sia fatto correttamente, ovviamente.

    • Il file flat non normalizzato non è "denormalizzato". È pieno zeppo di duplicazioni (non è stato fatto nulla per rimuovere i gruppi ripetuti e le colonne duplicate o per risolvere le dipendenze) e null, è un problema di prestazioni in molti modi e previene la concorrenza.

    • Per essere denormalizzato, deve prima essere normalizzato, quindi la normalizzazione è leggermente indietreggiata per qualche buona ragione. Dal momento che non è Normalizzato in primo luogo, non può essere Denormalizzato. È semplicemente non normalizzato.

    • Non si può dire che sia denormalizzato "per la performance", perché essendo un maiale della performance, è l'antitesi stessa della performance. Ebbene, hanno bisogno di una giustificazione per la mancanza di un design formale], e "per le prestazioni" è così. Anche il più piccolo esame formale ha messo in luce la rappresentazione ingannevole (ma pochissime persone possono fornire, quindi rimane nascosta, finché non riescono a convincere un estraneo ad affrontare, hai indovinato, l'enorme problema di prestazioni).

    • Le strutture normalizzate funzionano molto meglio delle strutture non normalizzate. Le strutture più normalizzate (EAV/6NF) hanno prestazioni migliori rispetto alle strutture meno normalizzate (3NF/5NF).

    • Sono d'accordo con la spinta di OMG Ponies, ma non con le loro etichette e definizioni

    • invece di dire "non "denormalizzare" a meno che non sia necessario" , sto dicendo, 'Normalizza fedelmente, punto' e 'se c'è un problema di prestazioni, non hai normalizzato correttamente' .

  2. Wikipedia
    Le voci per Moduli normali e Normalizzazione offrono definizioni errate; confondono le Forme Normali; sono carenti rispetto al processo di Normalizzazione; e danno uguale peso a NF assurde o discutibili che sono state sfatate molto tempo fa. Il risultato è che Wikipedia si aggiunge a un argomento già confuso e raramente compreso. Quindi non perdere tempo.

    Tuttavia, per progredire, senza che quel riferimento costituisca un ostacolo, lasciatemi dire questo.

    • La definizione di 3NF è stabile e non è cambiata.
    • C'è molta confusione tra le NF tra 3NF e 5NF. La verità è che questa è un'area che è progredita negli ultimi 15 anni; e molte organizzazioni, accademici e fornitori con i loro prodotti con limitazioni, si sono lanciati per creare una nuova "forma normale" per convalidare le loro offerte. Tutti al servizio di interessi commerciali e accademicamente malsani. 3NF nel suo stato originale non alterato intendeva e garantiva determinati attributi.
    • La somma totale è, 5NF è oggi, ciò che 3NF doveva essere 15 anni fa, e puoi saltare le battute commerciali e le dodici NF "speciali" (commerciali e pseudo-accademiche) nel mezzo, alcuni di cui sono identificati in Wikipedia, e anche quello in termini confusi.

  3. Quinta forma normale
    Dato che sei stato in grado di comprendere e implementare l'EAV nel tuo post, non avrai problemi a capire quanto segue. Ovviamente un vero modello relazionale è prerequisito, chiavi forti, ecc. La quinta forma normale lo è, poiché stiamo saltando la quarta:

    • Terza forma normale
      • che in termini semplici e definitivi è che ogni colonna non chiave in ogni tabella ha una relazione 1::1 con la chiave primaria della tabella,
      • e a nessun'altra colonna non chiave
    • Nessuna duplicazione dei dati (il risultato, se la normalizzazione è progredita diligentemente; non raggiunto solo dall'intelligenza o dall'esperienza, o lavorando per raggiungerlo come obiettivo senza il processo formale)
    • nessuna anomalia di aggiornamento (quando aggiorni una colonna da qualche parte, non devi aggiornare la stessa colonna che si trova da qualche altra parte; la colonna esiste in una e solo una posizione).
    • Se capisci quanto sopra, 4NF, BCNF e tutte le stupide "NF" possono essere respinte, sono richieste per i sistemi di archiviazione dei record fisici, promossi dagli accademici, abbastanza estranei al modello relazionale (Codd).

  4. Sesta forma normale

    • Lo scopo è l'eliminazione dei dati mancanti (colonne degli attributi), ovvero l'eliminazione dei Null
    • Questa è l'unica vera soluzione al problema Null (chiamato anche Gestione dei valori mancanti) e il risultato è un database senza Null. (Può essere fatto a 5NF con standard e sostituti Null, ma non è ottimale.) Il modo in cui interpreti e visualizzi i valori mancanti è un'altra storia.
    • Tecnicamente, non è una vera Forma Normale, perché non ha 5NF come prerequisito, ma ha un valore

  5. EAV vs sesta forma normale
    Tutti i database che ho scritto, tranne uno, sono puri 5NF. Ho lavorato con (amministrato, riparato, migliorato) un paio di database EAV e ho implementato molti veri database 6NF. EAV è un'implementazione libera di 6NF, spesso eseguita da persone che non hanno una buona conoscenza della normalizzazione e delle NF, ma che possono vedere il valore e hanno bisogno della flessibilità di EAV. Sei un esempio perfetto.

    La differenza è questa:poiché è sciolto e poiché gli implementatori non hanno un riferimento (6NF) a cui essere fedeli, implementano solo ciò di cui hanno bisogno e lo scrivono tutto nel codice; che finisce per essere un modello incoerente.

    Considerando che una pura implementazione 6NF ha un puro punto di riferimento accademico, e quindi è solitamente più rigida e coerente. In genere questo si presenta in due elementi visibili:

    • 6NF ha un catalogo per contenere i metadati e tutto è definito nei metadati, non nel codice. EAV non ne ha uno, tutto è nel codice (gli implementatori tengono traccia degli oggetti e degli attributi). Ovviamente un catalogo facilita l'aggiunta di colonne, la navigazione e permette di formare utilità.
    • 6NF, una volta compreso, fornisce la vera soluzione a The Null Problem. Gli implementatori EAV, poiché sono assenti dal contesto 6NF, gestiscono i dati mancanti nel codice, in modo incoerente o, peggio, consentono i valori Null nel database. Gli implementatori di 6NF disabilitano i Null e gestiscono i dati mancanti in modo coerente ed elegante, senza richiedere costrutti di codice (per la gestione dei Null; ovviamente devi ancora programmare per i dati mancanti).

Per esempio. Per i database 6NF con un catalogo, ho una serie di processi che [ri]generano l'SQL richiesto per eseguire tutti i SELECT e fornisco viste in 5NF per tutti gli utenti, quindi non hanno bisogno di conoscere o comprendere la struttura 6NF sottostante . Vengono espulsi dal catalogo. In questo modo le modifiche sono facili e automatizzate. I tipi EAV lo fanno manualmente, a causa dell'assenza del catalogo.

Discussione

Ora possiamo avviare la discussione.

"Ovviamente può essere più astratto se i valori sono predefiniti (Esempio:le specialità potrebbero avere una propria lista)"

Sicuro. Ma non diventare troppo "astratto". Mantenere la coerenza e implementare tali elenchi nello stesso modo EAV (o 6NF) degli altri elenchi.

"Se adotto l'approccio astratto può essere molto flessibile, ma le query saranno più complesse con molti join. Ma non so se ciò influisca sulle prestazioni, l'esecuzione di queste query 'più complesse'."

  1. I join sono pedonali nei database relazionali. Il problema non è il database, il problema è che SQL è ingombrante nella gestione dei join, in particolare delle chiavi composte.

  2. I database EAV e 6NF hanno più Join, che altrettanto pedonali, né più né meno. Se devi codificare ogni SELECT manualmente, certo, l'ingombrante diventa davvero ingombrante.

  3. L'intero problema può essere eliminato (a) utilizzando 6NF su EAV e (b) implementando un catalogo, dal quale è possibile (c) generare tutto l'SQL di base. Elimina anche un'intera classe di errori.

  4. È un mito comune che i Join in qualche modo abbiano un costo. Totalmente falso.

    • Il join viene implementato in fase di compilazione, non c'è nulla di sostanziale nel 'costare' i cicli della CPU.
    • Il problema è la dimensione delle tabelle essere uniti, non il costo dell'unione tra gli stessi tavoli.
    • Unire due tabelle con milioni di righe ciascuna, su una relazione PK⇢FK corretta, ognuna delle quali ha gli indici appropriati
      (Unico sul lato padre [PK]; Univoco sul lato Figlio [PK=parent FK + qualcosa]
      è istantaneo
    • Laddove l'indice Child non è univoco, ma almeno le colonne iniziali sono valide, è più lento; dove non c'è un indice utile, ovviamente è molto lento.
    • Non ha nulla a che fare con il costo di iscrizione.
    • Dove vengono restituite molte righe, il collo di bottiglia sarà la rete e il layout del disco; non l'elaborazione del join.

  5. Quindi puoi ottenere il "complesso" che desideri, non ci sono costi, SQL può gestirlo.

Mi interesserebbe sapere quali sono gli aspetti positivi e negativi di entrambi i metodi. Posso solo immaginarlo da solo, ma non ho l'esperienza per confermarlo.

  1. 5NF (o 3NF per chi non ha fatto la progressione) è il più semplice e migliore, in termini di attuazione; facilità d'uso (sviluppatori così come utenti); e manutenzione.

    • Lo svantaggio è che ogni volta che aggiungi una colonna, devi cambiare la struttura del database (tabella DDL). In alcuni casi va bene, ma non nella maggior parte dei casi, a causa del cambio di controllo in atto, piuttosto oneroso.
    • In secondo luogo, devi cambiare il codice esistente (il codice che gestisce la nuova colonna non conta, perché è un imperativo):dove sono implementati buoni standard, questo è ridotto al minimo; dove sono assenti, la portata è imprevedibile.

  2. EAV (che è ciò che hai pubblicato), consente di aggiungere colonne senza modifiche DDL. Questo è l'unico motivo per cui le persone lo scelgono. (il codice che gestisce la nuova colonna non conta, perché è un imperativo). Se implementato bene, non influirà sul codice esistente; in caso contrario, lo farà.

  3. Ma hai bisogno di sviluppatori compatibili con EAV.

    • Quando EAV è implementato male, è abominevole, un pasticcio peggiore di 5NF fatto male, ma non peggio di Non normalizzato, che è ciò che la maggior parte dei database là fuori (travisato come "denormalizzato per le prestazioni").
    • Ovviamente, è ancora più importante (rispetto a 5NF/3NF) mantenere un forte contesto di Transazione, perché le colonne sono molto più distribuite.
    • Allo stesso modo, è essenziale mantenere l'integrità referenziale dichiarativa:i pasticci che ho visto sono stati in gran parte dovuti agli sviluppatori che hanno rimosso il DRI perché è diventato "troppo difficile da mantenere", il risultato è stato, come puoi immaginare, una madre di un mucchio di dati con righe e colonne 3NF/5NF duplicate dappertutto. E gestione Null incoerente.

  4. Non vi è alcuna differenza nelle prestazioni, supponendo che il server sia stato ragionevolmente configurato per lo scopo previsto. (Ok, ci sono ottimizzazioni specifiche che sono possibili solo in 6NF, che non sono possibili in altre NF, ma penso che sia al di fuori dello scopo di questo thread.) E ancora, EAV fatto male può causare colli di bottiglia inutili, non più di quanto Non normalizzato.

  5. Ovviamente, se vai con EAV, ti consiglio più formalità; compri l'intero quid; vai con 6NF; realizzare un catalogo; utilità per produrre SQL; Visualizzazioni; gestire i dati mancanti in modo coerente; eliminare del tutto i null. Questo riduce la tua vulnerabilità alla qualità dei tuoi sviluppatori; possono dimenticare i problemi esoterici di EAV/6NF, utilizzare le visualizzazioni e concentrarsi sulla logica dell'app.