Mejor manera de almacenar los datos en la base de datos cuando no se conoce el tipo

Question

Tengo una tabla en mi base de datos que representa los campos de datos en un formulario personalizado. El DataField da una representación de lo que tipo de control que deben estar representados, y qué tipo de valor que debe tomar. Simplificado que se puede decir que tengo 2 entidades en esta tabla - Cuadro de texto de tomar cualquier cadena de cuadro de texto y teniendo sólo números.

Ahora tengo los diferentes valores almacenados en una tabla separada, haciendo referencia a la definición de campo de datos. ¿Cuál es la mejor manera de almacenar el valor de los datos aquí, cuando el tipo se diferencia?

Una posible solución es que el campo de un asimiento tabla ValorDelCampo por posible tipo de valor. Ahora bien, esto sin duda sería redundante, pero al menos tendría el valor almacenado en su forma correcta - la simplificación de las consultas más adelante.

FieldValue
----------
Id
DataFieldId
IntValue
DoubleValue
BoolValue
DataValue
..

Otra posibilidad es simplemente almacenando todo como cuerdas, y proyectando esto en las consultas. Estoy usando .Net con NHibernate, y veo que al menos aquí hay una Projections.Cast que puede ser empleado para la emisión, por ejemplo, cadena a int en la consulta.

De cualquier manera, en estas dos soluciones que necesito saber qué tipo de uso al hacer la consulta, pero yo sé que desde el DataField, por lo que no será un problema.

De todos modos; No creo que ninguna de estas soluciones suena bien. ¿Son ellos? ¿O hay un mejor camino?

Answer 1

No hay ninguna opción tercero "mágica":. A su situación específica determina la forma en que desea continuar

A partir de mi experiencia, una solución de cadena sólo tiene sentido con cosas como la configuración de la aplicación. Por lo general, no necesito a utilizar tales datos en consultas directamente por lo que no me molesta tanto que es en forma de cadena.

No estoy seguro, pero parece ser el caso de que usted está ampliando una entidad con atributos personalizados, que suena como es posible que desee hacer algo de procesamiento en la base de datos en algún momento. En este caso, es posible que también vaya con el enfoque de varias columnas de relleno y sólo en la columna con el tipo correcto. No va a ser bonito, pero podría simplificar las consultas.

Como ya he dicho, depende de si y qué tipo de consultas que necesita para funcionar, qué tipo de rendimiento que necesita, etc.

Answer 2

Al tirar de la idea de almacenamiento de datos multi-arrendatario, se puede utilizar el 'Nombre-pair' idea valores como se describe en MSDN . De alguna manera creo que este artículo va a ser más útil, aparte de la sección específica señalada.

En efecto, para hacer esto una solución escalable, que tendrá que definir los tipos de datos para el formulario personalizado utilizando una tabla de metadatos en el que se define el tipo real de los datos que desea almacenar (por ejemplo, bool, texto, int , fecha y hora). También puede considerar el almacenamiento del tipo .Net, así, ya que esto puede ser capaz de ayudarle en lo que respecta a la validación de entrada, etc. Otros detalles que se pueden almacenar, así es el nombre de los campos como se puede esperar que aparezcan en el formulario personalizado. Usando este enfoque se construye un formulario personalizado basado en los metadatos almacenados.

Me han utilizado con éxito este enfoque y funciona muy bien. Como complemento, también se utiliza la tabla de metadatos para definir si el valor esperado para el campo personalizado es proporcionada por el usuario (por ejemplo, nombre, fecha de nacimiento) o un valor del sistema de pre-definido en la caída-downlist (por ejemplo, una lista de citye, los países ). Para apoyar esto, tenemos una tabla adicional, que contiene las opciones de la lista que se vincula de nuevo a la tabla de metadatos.

Answer 3

Si sólo tiene 2 cuadros de texto que el usuario puede introducir valores en, y va a ser una cadena o un número, lo que realmente necesita para ser capaz de distinguir entre int y doble, no puedes simplemente almacenarlo todos como un tipo numérico adecuado (dependiendo de la DB). Que le llevaría a sólo 2 tipos diferentes y luego una posible solución sería tener 2 tablas, una para cada uno de los dos tipos.

En general, sin embargo, cada vez que veo que es difícil saber qué tipo de datos que algo va a ser empezaría preocupante que el proyecto está tratando de convertirse en genérico que tiene una tendencia a llegar a ser bastante desordenado.

Answer 4

Antes de ofrecer mi punto de vista .. Yo diría que es posible que tenga que volver a la mesa de ER. Supongo que un CustomForm tiene muchos Los campos y que éstos Los campos son de diferentes tipos (texto, datos, tal vez incluso de comportamiento y estilo), en lugar de generalizar el concepto el campo podría valer la pena en lugar de considerar la creación de una tabla para cada tipo de campo. P.ej. DateField, UserNameField, etc Esto hará que el tipo de valor sea exactamente una columna no nulo con el tipo correcto. También me gustaría apostar esto sería simplificar el código (menos condiciones para comprobar, el PP le da toda la información.)

Dicho esto, es posible que no sea capaz de volver a la mesa de ER o puede haber subyacentes razones válidas para hacer el enfoque de múltiples columnas-per-tipo. Aquí están algunos pros y los contras de tal enfoque.

Pros

• todo en una mesa, puede llegar a ser más rápido (aunque recuerde la raíz de todos los males es ..)

Contras

• DB no puede hacer cumplir que no se especifica más de un valor (código adicional para comprobar excepciones)
• DB no puede hacer cumplir que al menos uno no es NULL (código adicional para comprobar si hay FieldValues ??sin ningún valor)
• Soporte complemento del nuevo tipo de datos requiere cambiar todos los datos existentes (añadiendo un valor NULL en columnas).

Si usted está atascado con el CustomForm > El campo -> ValorDelCampo que sugeriría la creación de una tabla por ValorDelCampo . por ejemplo.

IntFieldValue
-------------
Id
DataFieldId
Value

DecimalFieldValue
-------------
Id
DataFieldId
Decimal


DateFieldValue
-------------
Id
DataFieldId
Date

Con lo anterior todavía se puede crear una vista que selecciona a partir de las tablas anteriores. La vista se puede crear una oferta una columna por tipo de valor y garantía que uno y sólo uno de ellos no es NULL. Esta es también más fácil de extender (añadir una nueva tabla, cambiar la vista, pero no requiere la actualización de los datos existentes con valores nulos para la columna de nuevo tipo).