¿Por qué almacenar banderas / enumeraciones en una base de datos como cadenas en lugar de enteros?

He estado examinando los volcados de SQL de algunos CMS famosos, incluidos Drupal 7, Wordpress (una versión bastante antigua) y algunas aplicaciones personalizadas basadas en Python.

Todos estos volcados contenían datos con indicadores de cadena en lugar de enteros. Por ejemplo, el estado de un mensaje se representa como published, closedo inheriten lugar de 1, 2o 3.

Tengo una experiencia bastante limitada en el diseño de bases de datos y nunca he pasado de SQL simples, pero siempre me enseñaron que debería usar indicadores numéricos / enteros para datos como este. Es obvio que tinyintconsume mucho menos espacio en una base de datos que, por ejemplo varchar(9),.

Entonces, ¿qué me estoy perdiendo? ¿No es esto un desperdicio de almacenamiento de datos y una redundancia de datos? ¿No sería un poco más rápido navegar, buscar e indexar si estas columnas usaran números enteros en lugar de cadenas?

Sí, almacenar cadenas en lugar de números puede usar más espacio. La razón por la que las plataformas de alto perfil lo están haciendo de todos modos es porque piensan que los beneficios de esa solución son mayores que el costo.

¿Cuales son los beneficios? Puede leer fácilmente un volcado de la base de datos y comprender de qué se trata sin memorizar las tablas de enumeración, e incluso las interfaces gráficas de usuario semioficiales simplemente pueden usar los valores mismos en lugar de transformar el registro que obtienen. (Esta es una forma básica de espacio en disco / tiempo de procesamiento de compensación).

¿Qué pasa con el costo? La capacidad de almacenamiento de datos no ha sido el cuello de botella en CMS durante mucho tiempo, ya que los discos se han vuelto tan grandes y baratos. El tiempo del programador, por otro lado, generalmente se vuelve más costoso, por lo que cualquier cosa que cambie el esfuerzo de desarrollo por espacio en disco también es algo bueno, desde una perspectiva comercial.

Sí, almacenar cosas como yeso truetomará más espacio que un tinyint. Esto no debería ser sorprendente. También hace que la indexación y, por lo tanto, las uniones sean menos eficientes para la base de datos. También tiene la penalidad de una posible confusión sobre cuál es el valor correcto ( yesvs y).

Sin embargo, hay muchos enfoques que se parecen a almacenar cadenas en la base de datos (en particular MySQL) que son eficientes.

Primero, MySQL tiene un enumtipo ( docs ) que puede parecerse mucho a un conjunto de cadenas booleano o restringido cuando se configura de esa manera. También exige que solo se ingresen valores válidos. Esto es a menudo mucho más útil que el almacenamiento 1, 2o 3como un valor ya que el significado se transmite con la información. La enumeración viene con la penalización de que se requiere un cambio de esquema para agregar o eliminar tipos.

Esto nos lleva a una tabla secundaria y claves foráneas (aplicable a todas las bases de datos). Sí, va a almacenar algún valor como clave (vuelta al 1, 2o 3) y el valor de published, closedy inheritse almacenan en otra mesa. Usando una vista ( docs ) es posible hacer que parezca que la tabla contiene la cadena en lugar de la clave. Esto tiene la ventaja de que no se requiere ningún cambio de esquema para agregar o eliminar entradas de la tabla secundaria.

Exactamente cómo se almacenan las cosas requeriría que uno mirara el DDL real del esquema para determinar qué método se usa y obtener alguna pista de qué compensaciones han seleccionado.