Perché archiviare flag / enum in un database come stringhe anziché come numeri interi?

Ho cercato dump SQL di alcuni CMS famosi, tra cui Drupal 7, Wordpress (una versione piuttosto vecchia) e alcune applicazioni personalizzate basate su Python.

Tutti questi dump contenevano dati con flag di stringa anziché interi. Ad esempio, lo stato di un post è stato rappresentato come published, closedo inheritpiuttosto che 1, 2o 3.

Ho un'esperienza piuttosto limitata nella progettazione di database e non ho mai superato semplici SQL, ma mi è stato sempre insegnato che dovrei usare flag numerici / interi per dati come questo. È ovvio che tinyintconsuma molto meno spazio in un database rispetto, ad esempio, a varchar(9).

Quindi cosa mi sto perdendo? Non è uno spreco di archiviazione dei dati e una ridondanza dei dati? Navigare, cercare e indicizzare non sarebbe un po 'più veloce se queste colonne usassero numeri interi anziché stringhe?

Sì, la memorizzazione di stringhe anziché di numeri può utilizzare più spazio. La ragione per cui le pltform di alto profilo lo stanno facendo è che pensano che i vantaggi di quella soluzione siano maggiori del costo.

Quali sono i vantaggi? Puoi facilmente leggere un dump del database e capire di cosa si tratta senza memorizzare le tabelle di enum e persino le GUI semi-ufficiali potrebbero semplicemente usare i valori stessi invece di trasformare il record che ottengono. (Questa è una forma base di compromesso tra spazio su disco / tempo di elaborazione.)

E il costo? La capacità di archiviazione dei dati non è stata il collo di bottiglia nel CMS da molto tempo, poiché i dischi sono diventati così grandi ed economici. Il tempo del programmatore, d'altra parte, di solito diventa più costoso, quindi tutto ciò che scambia lo sforzo di sviluppo per lo spazio su disco è anche una buona cosa, dal punto di vista aziendale.

Sì, la memorizzazione di cose come yeso trueoccuperà più spazio di una minuscola. Questo non dovrebbe essere una sorpresa. Inoltre rende l'indicizzazione e quindi i join meno efficienti per il database. Ha anche la penalità della possibile confusione per qual è il valore corretto ( yesvs y).

Tuttavia, esistono molti approcci simili all'archiviazione di stringhe nel database (in particolare MySQL) che sono efficienti.

Innanzitutto, MySQL ha un enumtipo ( documenti ) che può assomigliare molto a un set booleano o a stringhe ristrette quando impostato in quel modo. Impone inoltre l'inserimento di valori validi. Questo è spesso molto più utile memorizzazione 1, 2o 3come valore il significato viene convogliato con le informazioni. L'enum viene con la penalità che è necessario un cambio di schema per aggiungere o rimuovere tipi.

Questo ci porta a una tabella figlio e chiavi esterne (applicabile a tutti i database). Sì, si memorizzano un certo valore come chiave (torna 1, 2o 3) e il valore di published, closede inheritsono memorizzati in un altro tavolo. Utilizzando una vista ( documenti ) è quindi possibile far sembrare che la tabella contenga la stringa anziché la chiave. Ciò ha il vantaggio che non è richiesta alcuna modifica dello schema per aggiungere o rimuovere voci dalla tabella figlio.

Il modo esatto in cui vengono archiviate le cose richiederebbe di guardare il DDL effettivo dello schema per determinare quale metodo viene utilizzato e ottenere qualche suggerimento su quali compromessi hanno selezionato.