related - update datatable c# entity framework

Si EAV es malo, ¿qué usar para los valores dinámicos?

Question

Necesito crear una base de datos donde la tabla del grupo de Accountgroup tenga campos dinámicos para que las Accounts puedan ingresar esos valores de campo dinámicos cuando sea necesario. Probablemente no sea importante, pero estoy usando C # con EF y Linq.

Es difícil para mí porque nunca hice algo así y, desde que hice mi investigación, todo el mundo dice que los sistemas EAV son horribles y que debes diseñarlos de manera diferente , el problema es que nadie te lo cuenta después, ¿cómo?

Entonces, ¿puede ayudarme y decirme cómo puedo implementar algo similar sin hacer EAV?

Esto es lo que tengo hasta ahora.

Answer 1

Bueno, en el nivel más simple, solo agrega los valores como columnas ; quizás usando el soporte de columna dispersa en la base de datos para que no tenga mucho impacto de tamaño. Esto evita tanto EAV como el efecto de plataforma interna, y significa que está almacenando los valores como valores normales y escritos .

Answer 2

Cuando empiece a usar los campos EAV para informes o BI, querrá dispararse en la cara.

1. Use un campo XML. La mayoría de las bases de datos tienen buen soporte XML, consultas XPath, indexación.

2. Cree un nuevo esquema para los campos diseñados por el usuario del inquilino. Deje que el usuario haga lo que quiera con ese esquema (dentro de lo razonable).

Por ejemplo

create table account_group (
id primary key references real_schema.accountgroup(id),
super_important_note_field text not null
);

Sí, puede hacer claves externas a través de esquemas.

Answer 3

El problema con las reglas generales es que pasan rápidamente de "generalmente es una mala idea hacer X " a "nunca hacer X ".

En general, EAV es una mala idea porque, en muchos sentidos, frustra el propósito de un esquema relacional y, por lo tanto, elimina muchas de las características y ventajas de un DBMS relacional y otras tecnologías basadas en RDBMS, como ORM como Entity Framework.

Sin embargo, hay ciertos problemas de diseño para los cuales RDBMS no encaja bien. Hay algunos que son tan malos que tuvo que inventarse una tecnología completamente nueva (p. Ej., NoSQL DB como MongoDB).

Hay momentos en que EAV es probablemente la mejor opción que le queda de un conjunto de opciones imperfectas. Si no sabe (no puede) cuál es su esquema antes, entonces EAV puede ser su mejor opción. Esto es especialmente cierto si su esquema no es importante. Considere, por ejemplo, un catálogo de productos en línea donde tiene una gran lista de productos, cada uno de los cuales tiene algunas características. No puede predecir de antemano qué productos tendrán qué características. Y al final, lo único que haces con las características del producto es volcarlas en una lista de "características: valor" de todos modos. Esta es una situación donde el esquema no es especialmente poderoso, por lo que vencerlo con EAV no es especialmente dañino.

Lo más importante es comprender lo que sus elecciones de diseño van a hacer con sus capacidades y operaciones. Todo el diseño es trade-off. El punto es hacer sus concesiones conscientemente. En lugar de "EAV is Evil", piensa en cambio: "EAV es un arma cargada, asegúrate de saber a qué pie lo estás apuntando".

Answer 4

EAV no es "malvado"; a veces se usa mal cuando otras soluciones pueden ser más apropiadas.

Si sus atributos son verdaderamente dinámicos y desea evitar la adición dinámica de columnas ¹ , entonces EAV es apropiado.

¹ Por ejemplo, para evitar bloquear la mesa o porque su ORM de su elección no funciona bien o porque simplemente hay demasiados.