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

[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.

[roman]

En lo de separar las opciones de la aplicación de las de los usuarios, quizá sea útil revisar qué hace vBulletin. Hay opciones como el número de mensajes por página que pueden establecerse a "Predeterminado del foro". Supongo entonces que cada foro puede asignársele un valor y esto se guardará en la base de datos, supongo. Esta es una opción de la aplicación pero que también puede ser del usuario. En fin, quizá pueda dar alguna idea.

// Saludos

[dec]

Hola,

Empezado por 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.

Desde luego que podría ser una solución utilizar una tabla con tantos campos como opciones de usuario, porque, siendo realistas, no sé yo hasta qué punto pueden acumularse las opciones de usuario... digamos que hubiera 5, 10, 20, quizás... lo que pasa es que entonces podríamos tener un poco de mieditis al plantearse añadir opciones, puesto que esto implicaría añadir un nuevo campo a la tabla... que al cabo podría ir acumulando campos hasta ser algo "monstruoso", ¿o no tanto?

Pero, lo de tener 20.000 registros en una tabla no es que me pánico ni nada de eso; lo que ma un poco de mal rollo es que esos 20.000 registros sean... cómo decirlo... ¿tan iguales?

Lo explicaré con un ejemplo. Loturak cuenta con una tabla de nombre "Enlaces" en donde se guardan los que los usuarios quieren. Esta tabla puede crecer y crecer, pero, al fin y al cabo hablamos de enlaces, puede haber un millón (y puede haberlos repetidos, en algunos de sus datos), pero, todos tiene su URL, su título, su descripción,... no sé... lo veo como algo razonable, porque me digo, hay un millón de registros, que se corresponden a un millón de enlaces: el asunto cuadra, no puede ser de otro modo, no caben en 100 registros un millón de enlaces.

Pero con las opciones no ocurriría eso, puesto que habría, digamos que veinte opciones distintas y miles y miles de registros... ¿No hay algo aquí que no está bien? Claro, por otro lado, ¿puede ser esto de otro modo? Es lo de antes, 20 opciones, 1000 usuarios: 20.000 registros... ¿pero puede ser de otro modo? Me parece que no, que si se plantea una tabla de opciones que contenga en realidad pares de claves y valores... no puede ser de otro modo...

En fin. Reconozco que todo esto es demasiado nuevo para mí, y que no me he documentado (no he leído) lo suficiente sobre el tema, ¡ni muchísimo menos!

Vuelvo a agradecer vuestros comentarios. Ahora mismo cada vez veo más la posibilidad de una tabla con tantos campos como opciones (claudicando un tanto en mis ambiciones de lograr algo más "abstracto") pero, básicamente, por la otra forma: los 20.000 registros de antes, no lo termino de ver nada claro...

Empezado por Román

En lo de separar las opciones de la aplicación de las de los usuarios, quizá sea útil revisar qué hace vBulletin. Hay opciones como el número de mensajes por página que pueden establecerse a "Predeterminado del foro". Supongo entonces que cada foro puede asignársele un valor y esto se guardará en la base de datos, supongo. Esta es una opción de la aplicación pero que también puede ser del usuario. En fin, quizá pueda dar alguna idea.

Desde luego, vBulletin probablemente pueda enseñar no poco a quien se quiera meter a investigar en su código fuente... No te quito la razón Román.

[dec]

Hola,

A ver si lo que se me acaba de ocurrir suena descabellado o no... ¿Qué tal si utilizamos la magnífica serialización de objetos que ofrece PHP? ¿Porqué no guardar, en un sólo campo de tipo "LongText" la instancia de la clase Opciones de los usuarios "serializada"? Podrían guardarse muchos pares de claves/valor.

Pienso en un "Array asociativo", como antes, al que podrían añadirse tantos elementos como fuera preciso, y que podría terminar guardado en la base de datos como digo: en un solo campo, junto al resto de la clase Opciones, previamente "serializada". Rizando un poco el rizo ni siquiera haría falta tabla de opciones (para usuarios), podría añadirse a la tabla Usuarios un campo "Opciones", precisamente. (*)

¿Qué os parece?

(*) Seguramente no; seguramente no estaría mal una tabla Opciones, salvo que, esta vez, contaría con un campo "LongText", como digo, que las almacenaría todas juntas.

[roman]

A mi me parece muy buena idea a menos que quisieras hacer búsquedas sobre las opciones de usuario, por ejemplo, ¿cuántos usuarios usan morado como color de texto sobre fonde verde? Tu clase OpcionesUsuario simplemente tendría que tener cuidado en dar valores por defecto cuando aumente opciones. Yo creo que es bastante buena la idea.

// Saludos

[[maeyanes]]

Empezado por dec

,
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.

Aquí una pequeña corrección, quise referirme a tener dos tablas separadas, una para las opciones de la aplicación y otra para las opciones de los usuarios, pero lo que pensé no lo plasmé bien en mi mensaje...

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.

Con lo que comentas, y siguiendo con mi propuesta, podrías tener las opciones con sus valores predeterminados bajo un ID de usuario con valor 0 o -1, así si deseas agregar una opción nueva, solo creas un registro nuevo para ese usuario. Ahora, para inicializar los valores predeterminados, al hacer un usuario login, se leen las opciones y sus valores de este ID de usuario, acto seguido, se leen las opciones modificadas del usuario.

Representado sería algo como esto:

Id_Usuario  Clave    Value
0           Opcion1  0
0           Opcion2  1
0           Opcion3  1 <--- hasta aquí, todas las opciones con sus valores predeterminados.
1           Opcion2  0 <--- el usuario con ID 1 solo modificó el valor de la opcion2.

Claro, tiene el pequeño inconveniente que se tendría que leer dos veces la tabla de opciones del usuario.

Empezado por dec

Hola,

A ver si lo que se me acaba de ocurrir suena descabellado o no... ¿Qué tal si utilizamos la magnífica serialización de objetos que ofrece PHP? ¿Porqué no guardar, en un sólo campo de tipo "LongText" la instancia de la clase Opciones de los usuarios "serializada"? Podrían guardarse muchos pares de claves/valor.

Pienso en un "Array asociativo", como antes, al que podrían añadirse tantos elementos como fuera preciso, y que podría terminar guardado en la base de datos como digo: en un solo campo, junto al resto de la clase Opciones, previamente "serializada". Rizando un poco el rizo ni siquiera haría falta tabla de opciones (para usuarios), podría añadirse a la tabla Usuarios un campo "Opciones", precisamente. (*)

¿Qué os parece?

(*) Seguramente no; seguramente no estaría mal una tabla Opciones, salvo que, esta vez, contaría con un campo "LongText", como digo, que las almacenaría todas juntas.

Aquí el inconveniente que le veo sería que si algún otro programador quiere agregar alguna funcionalidad a la aplicación y esta conlleve opciones de usuario nuevas, tendría que modificar la clase opciones para agregarlas.


Saludos...

[*Emilio*]

Empezado por dec

Desde luego, vBulletin probablemente pueda enseñar no poco a quien se quiera meter a investigar en su código fuente... No te quito la razón Román.

Por lo poco/mucho que conozco vBulletin puedo decirte básicamente lo que hace...

1.- Comprueba si hay cookies.
2.- Comprueba que hay sesión iniciada.

2.- Si no hay ni sesión ni cookies (puede haber cookies sin sesión), entonces carga los valores por defecto.

3.- El usuario inicia session, carga datos de la BBDD a sesión y carga datos en las cookies.

Y ese es básicamente el funcionamiento del que antes te hablé.