Almacenamiento de preferencias de usuario muy granulares

Question

He visto algunas preguntas aquí sobre el almacenamiento de las preferencias de los usuarios, pero parecen referirse principalmente a un conjunto de preferencias bastante mínimo. Actualmente estoy trabajando en una aplicación web altamente personalizable, que tendrá que almacenar una gran cantidad de preferencias, y estoy luchando con la forma de almacenarlas.

El tipo de preferencias que almacenaré incluyen booleanos para mostrar información sobre herramientas específica, disposición de varios paneles de contenido en una página, qué página mostrar después del inicio de sesión, valores predeterminados para campos de formulario específicos, etc. Espero que haya más de 50 preferencias de este tipo para cada usuario, los datos son principalmente booleanos y enteros.

No soy un gran fanático de la serialización, pero me preocupa la escalabilidad de almacenar cada preferencia como una fila individual. Pensamientos?

Answer 1

Serializar un conjunto de datos es el camino a seguir aquí, pero no por razones de rendimiento, sino porque este es un aspecto del sistema que probablemente verá una gran cantidad de cambios. No desea tener que cambiar su esquema de base de datos solo porque ahora necesita permitir una preferencia para activar el modo avanzado en alguna página o algo.

El modelo de entidad-atributo-valor que menciona HLGEM se ajusta a esto desde un "fácil de evolucionar" perspectiva, pero como él dice, tendría un rendimiento muy pobre.

Lo que renunciaría a los objetos serializados sería la capacidad de consultar directamente a la base de datos para usuarios que coincidan con un patrón determinado (tal vez esté rastreando un error que ocurriría solo con alguna combinación de configuraciones y desea ver si tienes usuarios que tienen esa combinación).

Answer 2

haga lo que haga, evite usar la estructura de valor de atributo de entidad para esto ( http: //en.wikipedia.org/wiki/Entity-Attribute-Value_model ) a menos que desee un sistema con un rendimiento muy malo. Una llamada a una tabla con 50 columnas será mucho más rápida que una llamada a una tabla a la que tendrá que unirse 50 veces para obtener toda la información que necesita.

Haría una tabla relacionada para cada grupo general de preferencias (preferencias de inicio de sesión, preferencias generales del sitio, página específica o preferencias de funciones) basándome en cómo pretende consultar las preferencias (si desea retirar todo al iniciar sesión vice, extraiga los necesarios para todo el sitio al iniciar sesión y los necesarios solo para áreas especializadas cuando el usuario los toque, por lo que es una combinación de los mismos) y tenga las columnas booleanas para el tipo de preferencias establecidas en eso. De esa manera, todas las preferencias que necesitará para cada área del sitio estarán en la misma tabla o como máximo dos o tres tablas, lo que hace que sea relativamente fácil recuperar la información. Este es un lugar donde el diseño es fundamental para el rendimiento (buscará preferencias todo el tiempo, por lo que incluso los milisegundos cuentan), por lo que realmente debe considerar el rendimiento primero en su diseño. Aquí es mucho más importante que cualquier deseo de hacer que esto parezca orientado a objetos o crear menos trabajo para el desarrollador en la configuración.

Answer 3

No sé si incluso almacenaría información como las preferencias de los usuarios en una base de datos. Parece que deseará ver muchas (si no todas) las preferencias de los usuarios tan pronto como el usuario inicie sesión; Si terminas haciendo un montón de consultas de db, tu sistema terminará bastante lento. En su lugar, recomendaría conservar TODAS las configuraciones del usuario en un solo archivo (o un solo registro en algún lugar), y tragarlo al por mayor y guardarlo en caché tan pronto como el usuario inicie sesión.

Answer 4

Suponiendo que los datos del usuario ya están almacenados en una base de datos, no veo ningún problema real almacenándolos todos en una fila, especialmente si es posible que tenga que hacer consultas basadas en los datos, es decir. seleccione todos los usuarios con preferencia A O B, etc.

Sin embargo, lo cargaría en una clase y persistiría en esa clase a través de algún tipo de mecanismo de almacenamiento en caché.

Answer 5

Si no necesita buscar en las preferencias, siempre puede almacenar las preferencias como XML y guardarlas en una " Preferencia " columna. Debería facilitar un poco la adición de nuevas preferencias en el futuro;)

Answer 6

Otra opción que podría hacer (si no necesita que sus elementos estén almacenados en una base de datos, por ejemplo, para verificar las estadísticas de cosas (quién hace qué, etc.)), podría simplemente poner todas sus configuraciones en una cookie y almacenar en su máquina.

por supuesto, con las cookies vienen todas las advertencias de usar cookies. pero solo otra idea ...

Answer 7

Hay ciertas preferencias que el usuario prefiere más (todos los animales son iguales pero algunos son más iguales que otros). Estos deben optimizarse específicamente para su recuperación y aplicación en la interfaz al iniciar sesión. A medida que disminuye la profundidad de preferencia, se pueden agregar utilizando cualquier criterio y guardar como columnas separadas posiblemente como matrices (por ejemplo, la columna de preferencia de fuente incluye el tipo, tamaño y color de fuente y se refiere a una tabla de fuentes) También indexe las columnas muy utilizadas utilizando herramientas de db y rediseñe para dividir columnas agregadas de modo que pueda identificar qué elemento de la agregación tiene mucha demanda.

En general, las preferencias del usuario tienden a ser muy estáticas (es decir, son como un hábito), no confunda los datos del usuario que son más mutables con las preferencias.