La "Tabella descrizione unica per domarli tutti" è appropriata?

Lascia che ti aiuti a metterci un dito sopra. Cerca i " Inner Platform Effect (anti-pattern) " per i pro (e soprattutto) contro.

[...] In the database world, developers are sometimes tempted to bypass the RDBMS, for example by storing everything in one big table with two columns labeled key and value. While this allows the developer to break out from the rigid structure imposed by a relational database, it loses out on all the benefits, since all of the work that could be done efficiently by the RDBMS is forced onto the application instead.

Ecco ulteriore lettura

I database lo fanno già per te, stai annidando la stessa logica e perdendo tutti i vantaggi che il database ti darebbe normalmente.

Un problema è che, prima o poi, uno di quei "mini-tavoli" all'interno del grande tavolo avrà bisogno di una colonna aggiuntiva. quindi cosa fai? Suddividilo in un tavolo separato? Ora hai la maggior parte delle tue ricerche in una tabella, ma uno o due oddball nelle loro tabelle. Oppure aggiungi la colonna nella tabella principale, che ti lascia un sacco di null.

Penso che la tabella di descrizione one sia problematica, ma ho assolutamente inserito dati non omogenei in modo più o meno normalizzato nelle tabelle di ricerca. Ad esempio, se devo memorizzare vari valori di data con informazioni chiave limitate associate a diverse tabelle principali, inserirò quelle in una singola tabella con una colonna identificativa per consentirmi di suddividerla in viste utili.

È una linea sottile. Un tavolo enorme con colonne extra e altre stranezze è difficile da mantenere ... Ma lo sono anche 500 piccole tabelle di ricerca iper-specializzate. Devi trovare un equilibrio. Mantieni i tuoi dati piuttosto normalizzati e non puoi sbagliare troppo.

Ho incontrato questo modello in diversi sistemi nella mia attuale azienda. Poiché tutte le risposte finora assumono una posizione negativa, fornirò alcune ragioni per cui questo schema è buono. I contro sollevati dagli altri post sono certamente degni di considerazione. Ma ci sono alcuni professionisti:

• È possibile scrivere un singolo livello di persistenza / business log rispetto a quella tabella "dati di riferimento" centralizzata. Diciamo che usi una sorta di ORM. In questo caso, devi solo scrivere una classe di persistenza, chiamiamola "ReferenceValue". Sotto il modello completamente normalizzato, dovresti scrivere una classe di persistenza per ogni tipo di riferimento che hai, come "PaymentStatus", "RequestUrgency", "OrderType", o qualsiasi altra cosa.

• Se è necessario che gli utenti dell'applicazione debbano essere in grado di modificare questi valori in tempo reale, è sufficiente scrivere una singola schermata e gli utenti possono modificare tutti i valori. Sotto il modello normalizzato, devi avere una logica diversa per modificare ogni diverso elenco di valori.

• È possibile centralizzare determinate regole aziendali attorno ai dati di "elenco di valori". Ad esempio, osservando i requisiti di modifica del punto precedente, cosa succederebbe se volessi un audit trail quando le persone hanno apportato modifiche. O cosa succede se si desidera che i valori siano "scaduti" ma rimangono nel sistema. O cosa succede se si desidera che determinati elenchi vengano ordinati in base a un ordine specifico, anziché solo in ordine alfabetico. Centralizzando "liste di valori" in un unico modello, centralizziamo tutte queste esigenze aziendali.

Ogni caso è diverso, quindi devi valutare i pro e i contro. Ma questo schema è certamente utilizzato nel settore, e non è privo di vantaggi.

Ho lavorato con questo modello. La convalida della chiave esterna era un incubo implementato nei trigger. Alla fine avremmo avuto bisogno di trigger in ogni caso, perché non permettevamo che i codici venissero aggiornati ai valori disabilitati. Ma quello era un ulteriore livello di integrità. L'integrità di base non avrebbe dovuto richiedere un trigger.

Rilascia la colonna del nome della tabella e hai un buon inizio su un modello per una tabella di codici standard. Costruisci un'interfaccia o una fabbrica e hai alcune funzionalità piacevolmente riutilizzabili. Consenti alle tabelle di codici di estendere il pattern in base alle esigenze.

Consenti al database di garantire l'integrità dei dati memorizzati. Questo è ciò che è stato progettato per fare. Il modello di tabella di codice singolo non consente al database di aiutarti.

Se hai a che fare con l'internazionalizzazione, potresti voler spostare la tabella descrittiva. Ciò consentirebbe descrizioni diverse in diverse lingue. Tuttavia, altri metodi sono disponibili anche per le applicazioni.