Opciones personalizables para los usuarios de una aplicación Web: posibles soluciones

[dec]

Hola,

¿Cómo va eso? ¿Y la vuelta al cole, bien? ¿Y el Madrid, otra vez campeón de Europa? ¿Eh? Bueno. Parabienes para todos.

A ver si podéis echarme una mano con mi "problema". Lo entrecomillo porque es más bien una duda, o varias, pero, ni corre prisa, ni es algo que esté causando ningún inconveniente. Veréis.

En Loturak, ya sabéis, esa Web a la que un Spammer se está refiriendo descaradamente en estos Foros (como le descubramos se va a enterar el pendejo), en Loturak, digo, estamos tratando de desarrollar lo que haga falta para que los usuarios puedan establecer determinadas "opciones" para el uso del sitio Web.

Ahora mismo el usuario ya puede cambiar una serie de datos, pero, el tema está en darle la posibilidad de establecer "verdaderas opciones" de la aplicación y no sólo sus propios datos de usuario.

Por ejemplo, algunos ya sabéis que Loturak muestra listados de enlaces a páginas Web, básicamente. Estos enlaces cuentan con una descripción, aunque no es obligatoria. Y esta descripción, por defecto, no aparece en el listado de enlaces: hay que hacer clic en una "lupa" para mostrarla.

Pues bien, de lo que se trataría es de dar la posibilidad al usuario de poder establecer si quiere que la descripción de los enlaces aparezca "visible" desde un principio o no, que aparezca como ahora, "oculta" hasta que se quiere echar un vistazo.

Eso sería un ejemplo de "opción de usuario", obviamente habría más, y de ahí el comerse un poco el coco para montar algo que escale, esto es, que se puedan añadir tantas opciones como sea preciso sin problemas. Ahora bien, mi cabecita no da para mucho, como se podrá apreciar.

He pensado en añadir una tabla a la base de datos de Loturak y ahí guardar las opciones de los usuarios, peeeeeeeeeeeeeeeeeero... siempre hay un pero, sobre todo si no se tiene mucha idea de lo que uno está haciendo, si se es un novato, prácticamente.

La table que mi mente privilegiada es capaz de imaginar podría estar formada por los siguientes campos:

Tabla Opciones. Campos:

opciones_id
opciones_id_usuario
opciones_clave
opciones_valor

Creo que no es importante, para lo que nos ocupa, especificar el tipo de estos campos, etc. El inconveniente que le veo a la tabla anterior podría resumirse en que aunque por un lado le veo todo el sentido del mundo, por el otro intuyo que ni es la mejor solución, ni siquiera una solución mínimamente aceptable.

Supongamos que el usuario tiene la posibilidad de escoger 20 opciones en la aplicación. Supongamos que hay 1000 usuarios registrados (que no llegará Loturak a eso, probablemente, pero, estamos suponiendo nada más). 20 opciones por 1000 usuarios son 20.000 mil registros en la tabla Opciones, tal y como yo soy capaz de plantearlo... y me parece que algo en mi planteamiento está rematadamente mal.

Otra cosa que se me ocurre al Hilo de esto es si alguna vez se me ocurre que necesito guardar en la base de datos las opciones de la propia aplicación, no ya de los usuarios. Por ejemplo, ahora se establecen una serie de constantes que son las que determinan algunos aspectos de la aplicación, pero, si llegáramos a ampliar el pobre apartado de "administración" conque cuenta Loturak... una de las gracias estaría en poder establecer opciones de la propia aplicación...

A mí se me mete en la cabeza que opciones son opciones, ora del usuario, ora de la aplicación, pero, que ambas cosas son opciones y deberían ir por tanto en la misma tabla Opciones... pero,... como que tampoco lo veo claro...

Mi "modelo" para esto último, es decir, sólo para las opciones de la aplicación, podría ser el Gestor de contenidos WordPress que, efectivamente, cuenta con una tabla "Opciones" y no sólo guarda en ella las suyas, pero, permite a los desarrolladores de Plugins hacer lo propio: crear opciones, escribirlas, leerlas, en fin.

O sea, de tratarse únicamente de guardar las opciones de la aplicación creo que más o menos estaría claro, podría seguirse el ejemplo de WordPress y la cosa mejor o peor funcionaría, pero, ¿qué pasa con las opciones de los usuarios? ¿Cómo se os ocurre a vosotros que podrían tratarse? ¿Acaso está demás utilizar la base de datos para esto y bastaría con "Cookies", por ejemplo? ¿Para veinte o más opciones? ¿Cómo lo véis vosotros?

Cualquier cosa que se os ocurra será bienvenida y agradecida. Saludos para todos y perdonar el pedazo de rollo que os acabo de soltar, que podría haberse resumido en pocas líneas, estoy seguro, peeeeeeeeeeero... siempre hay un pero.

Gracias de verdad a todos de antemano.

[[maeyanes]]

Para las opciones de la aplicación si es bueno la tabla opciones, con los campos clave y valor.

Para las opciones de los usuarios, podrían darse dos situaciones...

Una tabla parecida a la de opciones de la aplicación, con un identificador al usuario (siguiendo tu ejemplo id_usuario). Ahora, leo que tu preocupación aquí es el número de opciones que pueden existir para un usuario y el número de registros que podría haber por usuario. Una posible solución sería solo guardar las opciones que el usuario cambie, o sea, si el usuario sigue usando el valor predeterminado de determinada opción, que este no se guarde, que se tome directamente de algun otro lado. La ventaja aquí sería la facilidad de agregar opciones nuevas.

La otra, una tabla con tantos campos como opciones tenga el usuario, la desventaja de esta posibilidad sería que al agregar una opcion nueva, tendrías que agregar un campo nuevo. La ventaja, cada usuario solo usaría solo un registro.

Espero que te sirvan de algo mis comentarios...



Saludos...

[roman]

¿Cuánto podría ocupar una opción? ¿1 byte? Digo, esto da opción a 256 valores para cada opción. Ok. Decíamos que había ¿cuantos? ¿mil usuarios por 20 opciones? En total 20,000 bytes. Guau, suena mucho. Pero, esperen un momento, eso son 20 kilobytes. En mi opinión eso no es nada.

// Saludos

[[maeyanes]]

Tal vez no le preocupa el espacio que ocupen, si no el volumen de información... digo, tal vez...



Saludos...

[roman]

O quizá la cantidad de datos

[dec]

Hola,

Gracias por vuestros comentarios. Por supuesto que son útiles. Sí; una posible solución podría estar en una tabla (para las opciones de los usuarios) que contuviese tantos campos como opciones, a costa de que añadir una opción significaría añadir un nuevo campo a dicha tabla. Bueno. Desde luego es algo que puede hacerse. Tampoco creo que las opciones crecieran como setas.

Por otro lado, atendiendo a lo que dice Román, pues, hombre, ocupar, lo que se dice ocupar, la mayoría de las opciones serían "booleanas", aunque el campo de la base de datos podría consistir en una enumeración cuyo rango estuviera entre 0 y 1. Es cierto que no parecen exagerados 20 KB para 20.000 opciones, puesto que hablamos de 1000 usuarios y Loturak crece a usuario por semana y somos ahora 85....

Las opciones en WordPress, la tabla de opciones en este gestor de contenidos, y, más concretamente, el campo que almacena el valor de dichas opciones es de tipo "longtext"... quiere decirse que no se trata de guardar un valor booleano, sino que pueden ir y de hecho van más allá (yo mismo escribí un Plugin para este sistema que guardaba en una opción varias líneas de texto sin problema alguno).

Tal vez una posible solución fuera considerar la posibilidad de separar las opciones de la aplicación y las opciones de los ususarios. Y que estas últimas fueran opciones "siempre" booleanas, de manera que el tamaño de la tabla de opciones no se fuera de madre. Podría ser, pero, no sé porqué (seguramente mi ignorancia y no otra cosa) no termino de verlo más o menos claro...

[[maeyanes]]

Lo más sano, desde mi punto de vista, sería tener las opciones de la aplicación y las de los usuarios por separado...

Y podrías probar con solo guardar en la tabla las opciones que no contengan el valor predeterminado. Esto es, cuando un usuario hace login, se inicializan las opciones del usuario con los valores predeterminados, acto seguido, lees de la tabla de opciones del usuario las opciones que haya modificado y asignas sus valores a las opciones correspondientes...

No se que te parezca...



Saludos...

[dec]

Hola,

Lo que parece claro es que si se quiere conseguir algo que escale y merezca la pena no va a ser moco de pavo, puesto que, por ejemplo, está el tema de consultar las opciones de un usuario, leerlas, escribirlas, actualizarlas, añadirlas,...

Se me ocurre emplear una clase Opciones que se encarge más o menos de todo esto, pero, desde luego, no creo que sea cuestión de ir añadiendo variables (propiedades) a esta clase por cada opción disponible, desde luego...

Pienso en una clase opciones con un "Array asociativo" que guardara las claves y los valores de las opciones, las cuales podrían cargarse al inicio de la sesión del usuario, y no volver a consultarse en la base de datos nunca más, a lo menos para "leer" dichos valores.

Esta clase habría de contar con métodos de escritura, lectura, actualización de opciones... ¡qué fregao, madre! Sin embargo, lo que más preocupa es el tema de la base de datos, de la posible tabla para las opciones...

Bueno. Gracias otra vez por vuestros comentarios, ¿eh? Siempre es bueno conocer la opinión de otros, puesto que quedarse con la de uno es posiblemente la mejor manera de ejecutar el salto del ángel en el pozo del error. Así que gracias otra vez.

[*Emilio*]

Creo que estás invirtiendo algo, dices que si tienes 1.000 usuarios con 20 opciones por usuario serán 20.000 registros, cosa que no me cuadra, entiendo que tendrás 1.000 registros en una tabla de 20 campos, por otra parte no veo problema en el tamaño incluso hablando de muchos miles de registros, si quieres ahorrar espacio en tus tablas no olvides hacer uso de VARCHAR en lugar de CHAR para tus campos string.

En cuanto al tema de guardar las opciones del usuario, ya sabes, se trata de hacer una combinación entre cookies, session y los datos guardados en tu base de datos, creo que no tienes dudas sobre esto, si las tienes dilo y le pegamos un repaso a ver que sacamos en limpio.

PD: Por supuesto la sesión en una clase, me gusta más así, pero para gustos....

[dec]

Hola,

Empezado por Maeyanes

Lo más sano, desde mi punto de vista, sería tener las opciones de la aplicación y las de los usuarios por separado...

Me parece que así es. Pienso que, al contener la tabla de opciones una campo "id_usuario", bien podría ser la aplicación un usuario más, salvo que contara con ciertas opciones conque el resto de usuarios no, lógicamente, pero, esto no me convence del todo ni mucho menos, porque, acaso estaríamos mezclando churras con merinas, por mucho que la aplicación pudiera considerarse un usuario más, no sería un usuario como los otros, y las opciones de los otros de nada servirían a la aplicación.

Empezado por Maeyanes

Y podrías probar con solo guardar en la tabla las opciones que no contengan el valor predeterminado. Esto es, cuando un usuario hace login, se inicializan las opciones del usuario con los valores predeterminados, acto seguido, lees de la tabla de opciones del usuario las opciones que haya modificado y asignas sus valores a las opciones correspondientes...

Aquí veo un inconveniente, seguro que porque en estos temas no estoy nada puesto. Como arriba (antes de que contestases) he dicho, me planteo una clase Opciones que se encargara de tratar con estas en la aplicación. En realidad ya se cuenta con una clase Usuario, y pienso que esta podría tener una variable/propiedad que podría albergar una instancia de un objeto de la clase Opciones.

De este modo, al crearse el objeto Usuario (que se crea al comienzo de la aplicación) podría aprovecharse para crear a su vez la instancia de la clase Opciones, y que esta se encargara ya de cargar las opciones del usuario en cuestión.

Ahora bien, tener opciones por defecto implica tener una lista de opciones predeterminada (¿O me equivoco?). Pero, ahora que lo pienso... tal vez es que no haya otra... no sé... la verdad es que contra más lo pienso me aparecen como posibles caminos a seguir, pero, enseguida encuentro algún obstáculo que me dice párate, no sigas por aquí, párate y mira esto...

Por ejemplo, ¿cómo se llevaría a cabo la inicialización de opciones? ¿Qué haría la clase Opcinoes en su inicialización? ¿Consultar la base de datos en busca de posibles opciones y guardarlas en el Array asociativo correspondiente para luego poder trabajar con estas? ¿Acaso debería la misma clase Opciones establecer una serie de opciones por defecto, de entrada, sin ni siquiera consultar a la base de datos? ¿Pero entonces para qué el Array asociativo? ¿Para otras opciones que no fueran las predeterminadas?

Pero he ahí otro problema (creo) y es que todas las opciones necesitan ser inicializadas al menos la primera vez que se piensen utilizar... digo yo, vamos... y me temo que al cabo habría que ir añadiendo y añadiendo opciones en la inicialización de la clase ídem...

No sé... disculpad que discurra de esta manera,... es lo que digo, habrá que darle vueltas a esto para no estar horas en realidad perdiendo el tiempo... no es que me importe, pero, tal vez sea bueno darle vueltas antes de escribir siquiera la primera línea de código.