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

El "model de fiesta" es un "patrón" para el layout de database relacional. Al less parte de esto implica encontrar elementos en común entre muchas entidades, como Cliente, Empleado, Socio, etc., y factorizar eso en algunas tablas de database más "abstractas".

Me gustaría conocer sus opiniones sobre lo siguiente:

  1. ¿Cuáles son los principios básicos y las fuerzas motivadoras detrás del model del partido?
  2. ¿Qué le prescribe que haga a su model 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é te ha llevado a sentir tu experiencia al respecto? ¿Lo usaste, y si es así, lo harías de nuevo? ¿Cuáles fueron los pros y los contras?
  4. ¿El model 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 objects de dominio y su model 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.

Gracias.

  1. ¿Cuáles son los principios básicos y las fuerzas motivadoras detrás del model del partido?

En la medida en que lo he usado, se trata principalmente de la reutilización y flexibilidad del código. Lo hemos usado anteriormente en el model 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.

  1. ¿Qué le prescribe que haga a su model 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).

Estás bastante correcto en tu parte anterior, aunque necesita más detalles. Puede imaginarse una situación en la que una entidad en la database (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 subclasss de la Parte. Desde mi punto de vista, tendrías una tabla Party y luego tablas más específicas para cada subclass, que luego podría ser subclasificada (Party -> Person -> Contractor).

  1. ¿Qué te ha llevado a sentir tu experiencia al respecto? ¿Lo usaste, y si es así, lo harías de nuevo? ¿Cuáles fueron los pros y los contras?

Tiene sus ventajas si necesita agregar de manera flexible nuevos types a su sistema y crear relaciones entre types que no esperaba al principio y al arquitecto en (usuarios que se mueven a un nuevo nivel, compañías que contratan otras compañías, etc.). También le brinda la ventaja de ejecutar una única consulta y recuperar datos para múltiples types de partes (Compañías, Empleados, Contratistas). Por otro lado, agrega capas adicionales de abstracción para get los datos que realmente necesita y aumenta la carga (o al less el número de uniones) en la database 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 database.

  1. ¿El model 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 objects de dominio y su model de datos físicos?

Esta es un área en la que estoy un poco débil, pero he descubierto que el uso de vistas y abstracción duplicada en la capa de aplicación no lo ha convertido en 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).

La idea detrás de los models de parte (también conocido como esquema de entidad) es definir una database que aproveche algunos de los beneficios de escalabilidad de las bases de datos sin esquema. El model de partido lo hace al definir sus entidades como loggings de tipo de partido, en oposition a una tabla por entidad. El resultado es una database 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 database que usan el model de parte son mínimas o nulas, ya que el esquema nunca cambia. Es esencialmente una estructura glorificada del model de datos de par key-valor con algunos nombres extravagantes y un par de attributes adicionales.

Pros:

  • Escalabilidad horizontal kick-ass. Una vez que sus 5-6 tablas están definidas en su model de entidad, puede ir a la playa y beber margaritas. Puede escalar virtualmente esta database tanto como desee con el mínimo esfuerzo.
  • La database 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.
  • Puede modelar cualquier entidad de datos arbitraria agregando loggings, sin cambiar el esquema. Lo que significa que puede decir adiós a los scripts de migration de esquema.
  • Este es el paraíso de los progtwigdores, ya que el código que escriben definirá las entidades reales que usan en el código, y no hay mapeos desde Objetos hasta Tablas ni nada por el estilo. Puede pensar en la tabla Party como el object base de su marco de trabajo (System.Object for .NET)

Contras:

  • Los models Party / Entity nunca funcionan bien con los ORM, así que olvídate de utilizar EF o NHibernate para get entidades semánticamente significativas de tu database de entidades.
  • Un montón de combinaciones. Desafíos de ajuste del performance. 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 models. Como todo es abstracto, no hay ningún diagtwig o visualización que pueda build en la parte superior de su database para explicar qué se almacena a otra persona.
  • Se necesitarán models 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 database en algún momento, y tu model de database no te va a ayudar esta vez.

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

Cuando formé 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 testings 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 model de información es usted.

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

Este es un tema extenso, recomendaría leer The Data Model Resource Book Volumen 3 – Patrones universales para el modelado de datos por Len Silverston y Paul Agnew.

Acabo de recibir mi copy y es bastante buena: le permite pasar por alto muchos enfoques del 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 los partidos, todos con sus ventajas y desventajas. La pregunta que fue aceptada como respuesta cubre solo una instancia de un "model de partido".

Por ejemplo, en muchos enfoques, conceptos como "Empleado", "Administrador de proyectos", etc. son roles que una parte puede desempeñar dentro de un context determinado. Trataré de darte un mejor queuepso una vez que llegue a casa.

No estoy seguro, pero el model 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.

como una simple plática de mi entendimiento: el modelado de fiestas brinda la flexibilidad y necesita más esfuerzo (como la unión de T-sql y …) para ser implementado.
También quiero señalar que, "el uso de Modelado de fiestas (serialization / generalización) le da la capacidad de tener relaciones FK con otras tablas". por ejemplo: piense en los diferentes types de usuarios (administrador, usuario, …) que se generalizan en User tabla User , y puede tener UserID User en su tabla Authorization .