2010-11-11 13 views
5

Estoy tratando de encontrar un tutorial que me guíe sobre cómo funcionan los campos personalizados basados ​​en el usuario. Al igual que en los sitios de encuestas, donde permiten a los usuarios crear campos personalizados y almacenarlos y, lo que es más importante, almacenar los datos ingresados ​​a través de esos campos.Cómo almacenar campos de usuario personalizados en la base de datos

Estoy buscando algo que describa cómo se hace esto en la base de datos. Tengo problemas para encontrar una forma de recuperar los datos una vez que los usuarios lo extraigan de Excel/cvs.

Respuesta

3

El Entity-Attribute-Value model se usa normalmente para manejar este escenario en una base de datos relacional. Una búsqueda rápida de "modelo EAV" arrojará más información de la que sabrá qué hacer.

+0

'Se espera que una búsqueda rápida para' 'modelo EAV' 'incluya la recomendación de que se debe evitar a menos que no haya alternativa, es muy flexible, pero no escala bien y puede ser difícil de consultar. Aquí hay un enlace a un estudio de caso: http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/ –

3

La sexta forma normal es la forma formal de implementar esto. Vaya con 3NF para todas las tablas y 6NF para la una o dos tablas que necesita para agregar columnas sin cambios de DDL. Utilizar con moderación.

EAV es el hijo bastardo de 6NF. Lo que eso significa es que las personas que lo hacen y escriben sobre él no tienen una comprensión formal de 6NF, por lo que a menudo crean monstruosidades.

Por supuesto, debe mantener buenos estándares: use datatypes; Integridad referencial declarativa (Claves extranjeras); etc. No dejes que esas cosas obtengan nada. Corre lejos de cualquiera que te diga que tienes que abandonarlos.

6NF/EAV es muy rápido, no hay ningún obstáculo para usar la capacidad de procesamiento del servidor. Nuevamente, corra como un infierno lejos de cualquiera que le diga que debe usar procesadores o cursores fila por fila o que no puede construir fácilmente las columnas de las filas. Publique de nuevo si tiene problemas específicos.

Esto requiere ir más allá de la capacidad actual (controles, DDL) de SQL; Para hacerlo de forma controlada y evitar la creación de monstruos no mantenibles, se necesita un pequeño catálogo para contener los metadatos. Si es inteligente, puede usarlo para generar el SQL reenviado para consultas, y así eliminar una gran cantidad de trabajo manual.

Hay mucha desinformación y algunas personas con "rep" no tienen ni idea. Para tener éxito técnicamente, necesitamos información precisa, no mitos y propaganda del miedo. Puede que le interese una publicación reciente en la que intenté set the recond straight.

0

Utilizamos 3 tablas para esto por tabla donde tenemos que admitir campos definidos por el usuario. Así, por ejemplo, si se quiere aplicar esto a su mesa de encuesta, se podría crear:

SURVEY_ATTRIBUTE 
- SurveyAttributeId 
- SurveyAttributeName 
- SurveyAttributeType 

SURVEY_ATTRIBUTE_CHOICE 
- SurveyAttributeChoiceId 
- SurveyAttributeChoice 
- SurveyAttributeId 

SURVEY_ATTRIBUTE_VALUE 
- SurveyAttributeValueId 
- SurveyId 
- SurveyAttributeValue 

El SURVEY_ATTRIBUTE tabla almacena un registro por atributo personalizado. La tabla SURVEY_ATTRIBUTE_VALUE almacena los atributos que están realmente asignados a las encuestas. Entonces, si un atributo no se aplica a un servey, nada se almacena. La tabla SURVEY_ATTRIBUTE_CHOICE almacena todas las opciones permitidas para los atributos de tipo 'LIST'.

El campo SurveyAttributeType en la tabla SURVEY_ATTRIBUTE se utiliza para describir el tipo del atributo. Solo usamos una pequeña cantidad de tipos permitidos como CHAR, DATE, NUMBER, LIST. Dependiendo de ese valor, nuestra aplicación sabe qué hacer con el valor almacenado en el campo SurveyAttributeValue. Por supuesto, puede formalizar esto más para permitir un rango más amplio, especificar las longitudes máximas de campo, etc., todo depende del nivel de libertad que desee darle a su usuario final. Tratamos de mantenerlo lo más simple posible porque nuestra audiencia objetivo no son los administradores de la base de datos sino los usuarios finales, por lo general no se preocupan por las longitudes de campo y demás.

También puede optar por omitir la tabla SURVEY_ATTRIBUTE_CHOICE y almacenar los valores permitidos en una cadena XML en el campo SURVEY_ATTRIBUTE. Eso dependerá de la forma en que va a implementar en su aplicación.

Cuestiones relacionadas