Pregunta

Una respuesta a una mi pregunta sobre diseño de DB sugirió algo que se llama herencia de tabla única. He buscado un poco sobre eso, pero parece que no puedo encontrar tanta información clara sobre eso.

Básicamente, lo que parece entender es que tiene una tabla grande con todos los campos y también un campo de tipo, y luego su capa ORM usa el campo de tipo para darle diferentes vistas de objetos. ¿Es eso correcto?

Más importante aún, ¿es la herencia de tabla única una técnica de diseño de base de datos 'aprobada'? Con eso quiero decir, ¿es 'sensato' usarlo? ¿También es seguro usarlo o causa problemas?

El otro problema es ¿qué tan bien funciona esto en los rieles? He encontrado algunas referencias a él en los rieles, pero ¿causa problemas al hacer las cosas de manera no convencional?

Cualquier ayuda muy apreciada.

¿Fue útil?

Solución

¿Es una buena idea? Depende. Se rompe la normalización en que una tabla no tiene un solo propósito. ¿Qué sucede cuando extiendes la clase base por enésima vez? Tendrás que agregar columnas a la tabla. La mayoría de los DB modernos no tienen ningún problema con eso, ya que puede modificar la tabla, pero ¿qué pasa con la refactorización y la eliminación de una clase? Ahora tiene columnas que no tienen un propósito.

Una regla general: si la mayoría del diseño se ha resuelto, probablemente sea seguro usarlo. Si el diseño cambia con frecuencia, tiene otros problemas y necesita bloquear sus casos de uso / requisitos de usuario. (sí, no es realmente compatible con XP)

No sé sobre los efectos de Rails.

Otros consejos

ITS es una forma de lidiar con un desajuste entre el pensamiento orientado a objetos y bases de datos. Permite una representación razonable de la información dentro de la base de datos y una representación diferente dentro del modelo de objeto.

Por ejemplo, tengo una aplicación donde cada uno de mis productos contiene una o más tarifas, cada una calculada de manera ligeramente diferente. Dentro de mi modelo de objetos, quiero tener subclases de una clase Fee, cada una de las cuales sabe cómo calcularse. Sin embargo, realmente no quiero tener una tabla por tipo de tarifa: así que creo la Tarifa como la clase base y las tarifas como la tabla, que contiene la unión de todos los campos necesarios en todos los subtipos, más un " tipo " ; columna cuyo valor corresponde al nombre de la subclase relevante. ActiveRecord maneja la plomería a partir de entonces.

En resumen, la herencia de tabla única (STI) es un patrón de diseño que permite un mapeo de las relaciones de herencia OOP a la base de datos. Si define alguna subclase de los objetos del modelo ActiveRecord, entonces debería considerar STI.

STI está (¿originalmente?) documentado en el libro de Martin Fowler "Patrones de arquitectura de aplicación empresarial", y también se describe en el libro canónico de DHH Rails 'Agile Web Development with Rails' (sección 18.4, creo). Le refiero a estos libros porque proporcionan una explicación mucho mejor de lo que yo podría esperar en este espacio.

Estoy totalmente en desacuerdo con el sentimiento expresado en www.matthewpaulmoore.com (vinculado por robintw en este hilo), que STI es inherentemente algo malo. Esta parece ser una visión algo ingenua que descuenta el uso de la herencia OOP. He utilizado STI para crear algunas soluciones elegantes en Rails, pero supongo que puede abusar de cualquier patrón de diseño.

Definitiva referencia . Permite que una sola tabla almacene múltiples objetos que tienen una clase base común.

Ruby on Rails utiliza una biblioteca llamada Registro activo . Este es un marco común de Ruby que admite STI.

Solo puedo hablar desde la (nueva) perspectiva ADO Entity Framework, que incluye la funcionalidad de tabla por tipo (TPT).

Aquí es un buena serie de publicaciones de blog que presentan los conceptos básicos (utilizando Entity Framework) y también hay un documento de MSDN aquí .

También parece haber alguna guía cuando se usa nHibernate para TPT, se encuentra aquí .

Existe este enlace que explica herencia de tabla por tipo en SQL Server . Esto parece tener un resumen bastante bueno y una introducción al concepto.

No estoy seguro de qué impacto tendría en Rails.

Generalmente lo encuentro útil, pero He encontrado algunos errores

El ejemplo en ese enlace puede proporcionar una imagen útil de cómo podría usarlo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top