Rails: usar ITS o no ... esa es la pregunta

Hace seis meses, hice una pregunta sobre el modelado de datos para mi aplicación, y recibí algunos consejos que me apuntaban hacia las ITS (ver Modelo de datos de Rails - pregunta sobre mejores prácticas para más detalles).

Jugué con él, lo hice funcionar un poco, y luego me distraje y puse el proyecto en pausa.

Recién comencé a desarrollarlo desde cero, con el beneficio de 6 meses más de experiencia en programación / ROR, y una vez más me he topado con este muro cuando se trata de modelar ingredientes para mis recetas de cerveza.

Para dar un resumen rápido, suponga que tengo tres tipos de ingredientes (malta, lúpulo y levadura): cada uno comparte algunos atributos (nombre, precio, proveedor), pero cada uno también tiene atributos específicos para ese tipo de ingrediente. Todos están relacionados (son todos ingredientes) pero tienen un "comportamiento" diferente (por ejemplo, los granos se trituran y habría lógica para lidiar con lo que no se aplicaría al lúpulo / levadura, etc.)

Los ingredientes son lo suficientemente diferentes que estoy considerando tener solo tres tablas separadas en la base de datos ... pero ¿qué pasa con los controladores? ¿Podría usar un solo controlador de ingredientes para administrar los modelos separados?

He leído sobre alternativas a STI (herencia de tabla de clase y herencia de tabla múltiple) pero todas las soluciones parecen poco claras. ¿Hay alguna alternativa que me brinde la conveniencia de STI (como obtener todos los ingredientes, independientemente del tipo, con una sola consulta de tabla) sin los inconvenientes (campos nulos, tablas difíciles de manejar cuando sigues agregando subclases y campos, etc.)

Lo siento, sé que esta pregunta es un poco confusa, pero siento que no puedo encontrar una solución limpia y ahora estoy tratando de averiguar qué método es el mal menor. Estoy seguro de que otros se han ocupado de esto, y me encantaría escuchar las ventajas y desventajas de las diferentes soluciones. ¡Gracias!

Si bien los campos nulos permanentes y las grandes tablas difíciles de manejar son conceptualmente feos, en general, en realidad no causan ninguna ineficiencia real. El espacio adicional utilizado por los campos nulos no es una consideración importante para la mayoría de los sistemas, y la velocidad de consulta no será más lenta si configura bien sus índices.

Y los beneficios de STI a menudo valen la pena (eficiencia de la base de datos al minimizar las uniones y simplicidad de código compartido y SECO). Entonces, si va a usar un sistema SQL tradicional, aprenda a ignorar la fealdad conceptual y use STI. Su caso de uso es para lo que STI fue diseñado.

Dicho esto, si no está demasiado inmerso en su ciclo de desarrollo para que este proyecto se adjunte a su sistema de base de datos (y parece que no lo está), y está dispuesto a invertir algo de tiempo para investigar / aprender, realmente podría desea considerar una alternativa a SQL (hay muchas buenas por ahí). Actualmente, la alternativa más popular (y mi favorita personal) es MongoDB .

MongoDB se basa en documentos más que en esquemas. Esto significa que no es tan rígido sobre lo que se puede almacenar en él. Debido a que MongoDB no tiene un esquema estructurado forzado, en su proyecto podría tener una sola colección de ingredients("colecciones" en MongoDB son similares a "tablas" en bases de datos SQL). Cada uno ingredienten esta colección podría haber compartido campos como se define en una Ingredientsuperclase (estos campos no se definirían en la propia base de datos). Y las subclases Malt, Hopsy Yeastpodrían tener sus propios campos individualizados (de nuevo, tal como se define directamente en estas subclases de modelo, no en la propia base de datos). Esto es exactamente lo que está buscando: le brinda toda la conveniencia de ITS sin su fealdad conceptual.

Bonificación adicional: es posible que el uso de un sistema de base de datos NoSQL como este ayude a simplificar también otras áreas de su aplicación. En muchos (¿la mayoría?) Dominios de negocios web comunes, NoSQL es una mejor opción que SQL, porque los dominios web tienden a ser particularmente intensivos en documentos (por lo que los documentos son una opción natural para el mecanismo de almacenamiento).

Resumen: si está vinculado al uso de una base de datos SQL debido a la administración o alguna parte de su aplicación que depende de ella, o si no tiene el tiempo para invertir en aprender algo nuevo, simplemente use STI. Si no está conectado a usar una base de datos SQL y tiene tiempo para aprender algo nuevo, le recomiendo que cambie a MongoDB u otra base de datos NoSQL basada en documentos.