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

7

Hace seis meses, hice una pregunta acerca de los datos de modelado de mi aplicación y recibí algunos consejos que me indicaban hacia STI (consulte modelo de datos de Rails - pregunta de mejores prácticas para los detalles).

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

Acabo de comenzar a desarrollarlo de nuevo desde cero, con el beneficio de 6 meses más de experiencia en programación / ROR, y una vez más he golpeado 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 diferentes "comportamientos" (por ejemplo, los granos se trituran y sería lógico lidiar con lo que no se aplicaría al lúpulo / levadura, etc.)

Los ingredientes son tan diferentes que estoy contemplando tener tres tablas separadas en la base de datos ... pero ¿qué pasa con los controladores? ¿Puedo 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 complicadas. ¿Existe 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 continúa 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!

    
pregunta Jim 21.02.2012 - 23:42

1 respuesta

6

Aunque los campos permanentemente nulos y las grandes tablas difíciles de manejar son conceptualmente feas, generalmente 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 las ITS a menudo valen la pena (la eficiencia de la base de datos al minimizar las uniones y la simplicidad y DRYness del código compartido). Entonces, si va a usar un sistema tradicional de SQL, simplemente aprenda a ignorar la fealdad conceptual y use STI. Su caso de uso es para lo que fue diseñado STI.

Dicho esto, si no está demasiado profundo 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 en investigación / aprendizaje, es posible que realmente desee considerar una alternativa a SQL (hay muchas buenas). Actualmente, la alternativa más popular (y mi favorita) es MongoDB .

MongoDB se basa en documentos y no 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 (las "colecciones" en MongoDB son similares a las "tablas" en las bases de datos SQL). Cada ingredient en esta colección podría tener campos compartidos como se define en una superclase Ingredient (estos campos no se definirían en la propia db). Y las subclases Malt , Hops y Yeast podrían tener sus propios campos individualizados (nuevamente, como se define directamente en estas subclases modelo, no en la propia db). Esto es exactamente lo que está buscando: le brinda toda la comodidad de las ITS sin su fealdad conceptual.

Bonificación adicional: es posible que el uso de un sistema de base de datos NoSQL como este también ayude a simplificar 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 especialmente 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 se basa en ella, o si no tiene tiempo para invertir en aprender algo nuevo, simplemente vaya con STI. Si no está conectado a usar una base de datos SQL y tiene tiempo para aprender algo nuevo, le recomiendo cambiar a MongoDB u otra base de datos NoSQL basada en documentos.

    
respondido por el Ben Lee 27.02.2012 - 21:17

Lea otras preguntas en las etiquetas