Puede crear una tabla auxiliar para mantener las referencias de los nombres de las propiedades. A continuación, puede vincular esa tabla con una tabla de fusión — entre un ID de usuario y el ID de una de las propiedades. Al hacerlo, siempre puede cambiar las propiedades.
Usando claves externas también puede “ cascade delete ” detalles del usuario que tienen una propiedad que ya no existe. Además, puede asegurarse de agregar solo referencias a nombres de propiedad válidos y optimizar la búsqueda mediante el uso de índices.
Digamos que:
CREATE TABLE user_preferences_headers
(
`id` INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
`name` VARCHAR(255) NOT NULL
);
CREATE TABLE `users`
(
`id` INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
`name` VARCHAR(255) NOT NULL,
`pass` VARCHAR(255) NOT NULL
);
CREATE TABLE `user_preferences`
(
`id_user` INT NOT NULL,
`id_preference_entity` INT NOT NULL,
`value` VARCHAR(255)
);
ALTER TABLE `user_preferences` ADD INDEX (`id_user`);
ALTER TABLE `user_preferences` ADD INDEX (`id_preference_entity`);
ALTER TABLE `user_preferences` ADD FOREIGN KEY (`id_user`) REFERENCES `users` (
`id`
) ON DELETE CASCADE ON UPDATE CASCADE ;
ALTER TABLE `user_preferences` ADD FOREIGN KEY (`id_preference_entity`) REFERENCES `user_preferences_headers` (
`id`
) ON DELETE CASCADE ON UPDATE CASCADE ;
Ahora selecciona por primera vez todas las cabeceras de user_preferences_headers
por su nombre, o no, y se utiliza el ID para seleccionar el valor deseado preferencia de un usuario (identificado también por id) de user_preferences
. Tenga en cuenta que cuando elimina una entrada en user_preferences_headers
, también se eliminarán todas las entradas que enlazan con el ID de la fila eliminada.
+1 para normalizar. Esta es una muy buena idea IMO. – Herbert