¿Cuáles son los principios y los beneficios del "modelo de partido"?

Question

El "modelo de fiesta" es un "patrón" para el diseño de bases de datos relacionales. Al menos parte de esto implica encontrar elementos en común entre muchas entidades, como Cliente, Empleado, Socio, etc., y factorizar eso en algunas tablas de base de datos más "abstractas".

me gustaría saber sus pensamientos en lo siguiente:

1. ¿Cuáles son los principios básicos y las fuerzas motrices detrás del modelo de partido?
2. ¿Qué le prescribe que haga a su modelo de datos? (Mi nivel anterior es bastante alto y posiblemente sea incorrecto de alguna manera. He estado en un proyecto que lo usó, pero estaba trabajando con un equipo separado centrado en otros temas).
3. ¿Qué experiencia te ha llevado a sentirte al respecto? ¿Lo usaste, y si es así, lo harías de nuevo? ¿Cuáles fueron los pros y los contras?
4. ¿El modelo de fiesta limitó su elección de ORM? Por ejemplo, ¿tuvo que eliminar ciertos ORM porque no permitían una "capa de abstracción" suficiente entre sus objetos de dominio y su modelo de datos físicos?

Estoy seguro de que cada respuesta no resolverá cada una de esas preguntas ... pero cualquier cosa que toque una o más de ellas me ayudará a tomar algunas decisiones que estoy enfrentando.

Gracias.

Answer 1

1. ¿Cuáles son los principios básicos y las fuerzas motrices detrás del modelo de partido ?

En la medida en que lo he usado, es sobre todo acerca de la reutilización de código y flexibilidad. Lo hemos usado anteriormente en el modelo de invitado/usuario/administrador y ciertamente demuestra su valor cuando necesita mover un usuario de un grupo a otro. Extienda esto para que las organizaciones y las empresas estén representadas con usuarios debajo de ellas, y realmente está proporcionando una forma de abstracción que no es particularmente inherente a SQL.

2. ¿Qué le prescribe hacer a su modelo de datos? (Mi bit de arriba es bastante alto nivel y muy posiblemente incorrecto de alguna manera. He estado en un proyecto que lo usó, pero yo estaba trabajando con un equipo diferente centrado en otros temas).

Es bastante correcto en su parte superior, aunque necesita más detalles. Puede imaginarse una situación en la que una entidad en la base de datos (llámala Parte) contrata a otra Parte, que a su vez puede subcontratar el trabajo. Una parte puede ser un Empleado, un Contratista o una Empresa, todas las subclases de la Parte. Desde mi punto de vista, tendrías una tabla Party y luego tablas más específicas para cada subclase, que luego podría ser subclasificada (Party -> Person -> Contractor).

3. ¿Qué experiencia ha llevado a sentir al respecto? ¿Lo usó, y si es , lo haría de nuevo? ¿Cuáles fueron los pros y los contras?

Tiene sus ventajas si necesita flexibilidad para añadir nuevos tipos a su sistema y crear relaciones entre los tipos que usted no esperaba al principio y al arquitecto (usuarios móviles a un nuevo nivel, la contratación de empresas otras compañías, etc.). También le brinda la ventaja de ejecutar una única consulta y recuperar datos para múltiples tipos de partes (Compañías, Empleados, Contratistas). Por otro lado, agrega capas adicionales de abstracción para obtener los datos que realmente necesita y aumenta la carga (o al menos el número de uniones) en la base de datos cuando consulta un tipo específico. Si su abstracción va demasiado lejos, es probable que necesite ejecutar múltiples consultas para recuperar los datos, ya que la complejidad comenzaría a ser perjudicial para la legibilidad y la carga de la base de datos.

4. ¿El modelo de partido limitar su elección de ORM? Por ejemplo, ¿ tiene que eliminar ciertos ORM porque que no permiten la suficiente cantidad de una "capa de abstracción" entre sus objetos de dominio y sus datos físicos modelo?

Esta es un área que estoy cierto que un poco débil, pero me he dado cuenta que el uso de vistas y la abstracción de espejo en la capa de aplicación no han hecho esto demasiado de un problema. El verdadero problema para mí siempre ha sido un "dónde está la parte de X de datos vivos" cuando quiero leer la fuente de datos directamente (no siempre es intuitivo para los nuevos desarrolladores en el sistema).

Answer 2

No estoy seguro, pero el modelo de fiesta suena como un caso particular del patrón de generalización-especialización. Una búsqueda sobre "modelación relacional de especialización de generalización" encuentra algunos artículos interesantes.

Answer 3

Este es un tema extenso, recomendaría leer The Data Model Resource Book Volume 3 - Universal Patterns for Data Modeling por Len Silverston y Paul Agnew.

Acabo de recibir mi copia y es bastante buena: le ofrece una visión general de muchos enfoques para el modelado de datos, incluidos los patrones híbridos de roles contextuales, etc. Ha detallado PROs y CONs para cada enfoque.

Hay una pletheora de maneras de modelar las relaciones y los roles de las partes con sus ventajas y desventajas. La pregunta que fue aceptada como respuesta cubre solo una instancia de un "modelo de partido".

Por ejemplo, en muchos enfoques, las nociones como "Empleado", "Administrador de proyectos", etc. son roles que una parte puede jugar dentro de un contexto determinado. Trataré de darte un mejor colapso una vez que llegue a casa.

Answer 4

Cuando formaba parte de un equipo que implementaba estas ideas a principios de los años 80, no limitó nuestra elección de ORM porque aún no se habían inventado.

Me gustaría recurrir a esas ideas en cualquier momento, ya que ese proyecto en particular fue una de las pruebas de concepto más convincentes que he visto de una idea "revolucionaria" (que sin duda era en ese momento).

Te obliga a nada. Y no te detiene de nada (de cualquier error, quiero decir). El que define su propio modelo de información es usted.

Todas las partes tienen muchas propiedades en común. El hecho de que tienen un nombre y tal (llamamos a esos "signaletics").El hecho de que tengan ubicaciones principales/principales llamadas "direcciones". El hecho de que todos están involucrados, en cierto sentido, en los contratos comerciales.

Answer 5

La idea detrás de los modelos del partido (también conocido como esquema de entidad) es definir una base de datos que aprovecha algunas de las ventajas de escalabilidad de las bases de datos sin esquema. El modelo de partido lo hace al definir sus entidades como registros de tipo de partido, en oposición a una tabla por entidad. El resultado es una base de datos extremadamente normalizada con muy pocas tablas y muy poco conocimiento sobre el significado semántico de los datos que almacena. Todo ese conocimiento se transmite al acceso a los datos en el código. Las actualizaciones de la base de datos que usan el modelo de parte son mínimas o nulas, ya que el esquema nunca cambia. Es esencialmente una estructura glorificada del modelo de datos de par clave-valor con algunos nombres extravagantes y un par de atributos adicionales.

Pros:

• Kick-culo escalabilidad horizontal. Una vez que sus 5-6 tablas están definidas en su modelo de entidad, puede ir a la playa y beber margaritas. Puede escalar virtualmente esta base de datos tanto como desee con el mínimo esfuerzo.
• La base de datos admite cualquier estructura de datos que arroje. También puede cambiar las estructuras de datos y las definiciones de fiestas/entidades sobre la marcha sin afectar su aplicación. Esto es muy muy poderoso.
• Usted puede modelar cualquier entidad de datos arbitraria mediante la adición de registros, sin cambiar el esquema. Lo que significa que puede decir adiós a los scripts de migración de esquema.
• esto es el paraíso de los programadores, ya que el código que escriben definirá las entidades actuales que utilizan en código, y no hay asignaciones de objetos a tablas o algo por el estilo. Se puede pensar en la tabla del partido como el objeto base de su marco de elección (System.Object para .NET)

Contras:

• modelos Fiesta/Entidad no jugar bien con ORM, por lo olvide sobre el uso de EF o NHibernate para obtener entidades semánticamente significativas de su base de datos de entidades.
• Un montón de combinaciones. Desafíos de ajuste del rendimiento. Este 'con' es relativo a las prácticas que usa para definir sus entidades, pero es seguro decir que hará mucho más de esas preguntas alucinantes que le traerán pesadillas por la noche.
• Más difícil de consumir. Los desarrolladores y profesionales de DB que no estén familiarizados con su negocio tendrán más dificultades para acostumbrarse a las entidades expuestas por estos modelos. Como todo es abstracto, no hay ningún diagrama o visualización que pueda construir en la parte superior de su base de datos para explicar qué se almacena a otra persona. se necesitarán
• modelos de acceso a datos pesados ​​o motores de reglas de negocio. Básicamente, tienes que hacer el trabajo de entender qué diablos quieres de tu base de datos en algún momento, y tu modelo de base de datos no te va a ayudar esta vez.

Si está considerando un esquema de parte o entidad en una base de datos relacional, probablemente debería echar un vistazo a otras soluciones como un almacén de datos NoSql, BigTable o KV Stores. Hay algunos productos geniales con despliegues masivos y tracción como MongoDB, DynamoDB y Cassandra que fueron pioneros en este movimiento.

Answer 6

como una simple conversación de mi entendimiento: el modelado Parte da la flexibilidad y necesita más esfuerzo (como T-SQL JOIN y ...) para ser implementado.
Yo también quiero que el punto "que el uso de modelos Party (serialización/generalización) da la posibilidad de tener FK-Relación a otras tablas". por ejemplo: piense en diferentes tipos de usuarios (administrador, usuario, ...)) que se generalizó en la tabla User, y puede tener UserID en su tabla Authorization.