Cita:
|
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...
Cita:
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:
Código:
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.
Cita:
|
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...