¿Qué son los patrones de diseño para admitir campos personalizados en una aplicación?

En cuanto al código de la aplicación, no estoy seguro. Sé que los campos personalizados se benefician mucho de un modelo EAV en la base de datos.

Según los comentarios a continuación, el error más significativo que puede cometer con este modelo es poner claves foráneas en él. Nunca jamás poner algo como friendId o TypeID en este modelo. Utilice este modelo junto con el modelo relacional típico y mantenga los campos de clave foránea en columnas de tabla como deberían.

Un segundo un error significativo es colocar datos en este modelo que deben ser reportados con cada elemento. Por ejemplo, poner algo como Username en este modelo significaría que cada vez que desee acceder a un usuario y necesite conocer su nombre de usuario, se ha comprometido a unirse a best o 2n queries donde n es el número de usuarios que está mirando. Cuando considera que normalmente va a necesitar la propiedad Username para cada elemento User, se hace obvio que esto también debe permanecer en la tabla columna.

Sin embargo, si solo está utilizando este modelo con campos de usuario personalizados, estará bien. No puedo imaginar muchas situaciones en las que un usuario estaría ingresando datos relacionales y el modelo EAV no es demasiado perjudicial para las búsquedas.

Por último, no intente unir datos de esto y obtener un bonito conjunto de registros. Agarra el registro original y luego agarra el conjunto de registros de la entidad. Si te sientes tentado a unirte a las mesas probablemente hayas cometido el segundo error como se mencionó anteriormente.

Si está desarrollando con un lenguaje orientado a objetos, estamos hablando de modelos de objetos adaptativos aquí. Hay bastantes artículos escritos sobre cómo puede implementarlos en oo-languages, pero no tanta información sobre cómo diseñar el lado del almacén de datos.

En la empresa donde trabajo, hemos resuelto el problema utilizando una base de datos relacional para almacenar datos de AOM. Tenemos una tabla de entidades central para presentar todas las diferentes "entidades" en el dominio, como personas, dispositivos de red, empresas, etc... Almacenamos los "campos de formulario" reales en tablas de datos que se escriben, por lo que tenemos una tabla para cadenas, una para fechas, etc. Todas las tablas de datos tienen una clave foránea que apunta a la tabla de entidades. También necesitamos tablas para presentar el lado del tipo, es decir, qué tipo de atributos (campos de formulario) puede tener cierta entidad y esta información se utiliza para interpretar los datos en tablas de datos.

Las ventajas de nuestra solución son que cualquier cosa se puede modelar sin cambios de código, incluyendo referencias entre las entidades, los múltiples valores y así sucesivamente. También es posible agregar reglas de negocio y validaciones a los campos y se pueden reutilizar en todas las formas. Las desventajas son que el modelo de programación no es muy fácil de entender y el rendimiento de la consulta será peor que con un diseño de base de datos más típico. Otra solución que la base de datos relacional podría haber sido mejor y más fácil para AOM.

Construir un buen AOM con un almacén de datos que funcione es mucho trabajo y no lo recomendaría si usted no tiene desarrolladores altamente calificados. Tal vez un día habrá una solución de sistema operativo para este tipo de requisitos.

Los campos personalizados se han discutido antes en SO:

• ¿Cómo crearía y almacenaría campos personalizados definidos por el usuario en una base de datos SQL?
• Para agregar la función de campos personalizados / definidos por el usuario o no?
• ¿Qué arquitectura puedo usar para manejar un carrito de compras donde cada producto requiere diferentes atributos ser salvado

Algo así como la Opción 3 es el camino a seguir y he utilizado este método anteriormente. Cree una sola tabla para definir propiedades adicionales y sus valores correspondientes. Esto sería una relación 1-N entre su Cliente y CustomerCustomField table (respectivamente). Su segunda pregunta con respecto a la definición de relaciones con propiedades personalizadas sería algo en lo que pensar. Lo primero que viene a la mente es agregar un campo de fuente de datos, que contendría la tabla a la que el valor de la propiedad está obligado a. Así que esencialmente su CustomerCustomField se vería como:

1. CustomerID
2. Propiedad
3. Valor
4. ValueDataSource (nullable)

Esto debería permitirle enlazar a una estructura de datos específica o simplemente permitirle especificar valores no enlazados. Puede normalizar aún más este modelo, pero algo como esto podría funcionar y debería ser lo suficientemente fácil de manejar en código.

La opción 4 o 5 sería mi elección. Si sus datos son importantes, no iría desechando su información de tipo con la opción 3. (Puede intentar implementar la comprobación de tipos completa usted mismo, pero es un trabajo bastante grande, y el motor de base de datos ya lo hace por usted.)

Algunos pensamientos:

• Asegúrese de que su CustomFields tiene una columna DataType.
  • Use una restricción de comprobación basada en UDF en CustomFieldValues para asegurarse de que la columna especificada por CustomFields.DataType no sea nula.
  • Usted también querrá un restricción de comprobación estándar para asegurarse de que tiene exactamente un valor no nulo.
• Con respecto a las claves foráneas, las modelaría como DataType por separado.
  • Cada posible referencia de la tabla cruzada requeriría su propia columna. Esto es bueno, porque mantiene la integridad referencial.
  • De todos modos, tendría que soportar estas relaciones en el código de la aplicación, por lo que el hecho de que estén codificadas en la base de datos no limita funcionalidad.
  • Esto también encajará bien con tuM, si estás usando uno.
• Para la opción 5, utilice tablas intermedias para modelar las relaciones.
  • Usted todavía tendría un CustomerCustomFieldValue, pero en su lugar con solo CustomerID y CustomFieldValueID columnas.
• Piensa largo y tendido sobre tus limitaciones en cada paso del camino. Esto es algo complicado, y un paso en falso puede causar un havok total en la línea.

Estoy usando esto en una aplicación actualmente en desarrollo. No ha habido ningún problema todavía, pero los diseños de EAV todavía me asustan. Sólo ten cuidado.

Como un aparte, XML también puede ser una buena opción. No se mucho al respecto por experiencia directa, pero fue una de las opciones que consideré al comenzar el diseño de datos, y parecía bastante prometedor.

Si esos campos 'extra' son incidentales y no me importa hacer búsquedas en ellos, generalmente opto por la opción 2 (pero me gusta JSON mejor que XML). Si va a haber búsquedas en campos personalizados, la opción 3 no es difícil de hacer, y generalmente el optimizador SQL puede obtener un rendimiento razonable de ella.

Actualmente estoy trabajando en un proyecto con este mismo problema, y he elegido usar la opción 3, pero agregué un campo FieldType y un campo ListSource en caso de que el FieldType="list". El campo ListSource podría ser una consulta, una vista sql, un nombre de función o algo que resulte en una lista de opciones para la lista. El mayor problema al tratar de almacenar campos como este en mi situación es que esta lista de campos puede cambiar, y los usuarios pueden editar los datos más tarde. Así que qué hacer si el la lista de campos ha cambiado y van a editar. Mi solución a ese escenario fue permitir la edición solo si la lista no ha cambiado y mostrar datos de solo lectura si lo ha hecho.