Mysql
 sql >> Base de données >  >> RDS >> Mysql

Le meilleur moyen de stocker les paramètres utilisateur dans MySQL ?

Pour tout ce qui est toujours défini pour chaque utilisateur, vous devriez avoir tendance à le conserver dans le Users tableau, selon la normalisation habituelle. En ce qui concerne la configuration facultative, j'ai tendance à aimer la structure de table suivante :

TABLE Users:
  id INT AI
  name VARCHAR
  ...

TABLE User_Settings
  user_id INT PK,FK
  name VARCHAR PK
  type BOOL
  value_int INT NULL
  value_str VARCHAR NULL

Où User_Settings.type spécifie si le champ entier ou chaîne doit être référencé.

c'est-à-dire :

INSERT INTO Users (id, name) VALUES (1, 'Sammitch');
INSERT INTO User_Settings (user_id, name, type, value_int) VALUES (1, 'level', 1, 75);
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'en');

Et pour le problème INSERT/UPDATE :

INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'fr')
  ON DUPLICATE KEY UPDATE value_str='fr';

De plus, comme la plupart des gens le disent, sérialiser et stocker les préférences n'est pas une très bonne idée car :

  1. Vous ne pouvez pas récupérer une seule valeur avec une requête, vous devez récupérer la chaîne sérialisée entière, la désérialiser et supprimer les données inutiles.
  2. Il est facilement corrompable et difficile à récupérer.
  3. C'est pénible d'écrire une requête brute, c'est-à-dire :pour corriger globalement un certain paramètre.
  4. Vous stockez essentiellement des données tabulaires dans un seul champ de table.

Modification rétrospective de septembre 2016 :

Dans l'intervalle, j'ai eu quelques disputes avec des gens sur la meilleure façon de stocker les paramètres facultatifs, ainsi que sur la structure générale des tables définie ci-dessus.

Bien que cette structure de table ne soit pas carrément mauvaise , ce n'est pas exactement bon Soit. C'est essayer de tirer le meilleur parti d'une mauvaise situation. La sérialisation des paramètres facultatifs peut fonctionner tant que vous pouvez vous adapter à ces paramètres :

  1. Tout est chargé en même temps, pas de sélection ni de choix.
  2. Ne pas être indexable, consultable ou facilement modifiable en masse .

Ensuite, vous pourriez envisager d'ajouter un champ comme optional_settings dans les Users table contenant une forme sérialisée [ex :JSON] des paramètres. Vous faites des compromis sur ce qui précède, mais c'est une approche plus simple et vous pouvez stocker des paramètres plus complexes.

Aussi, si vous utilisez un type LOB comme TEXT pour le stockage les données ne sont pas forcément stockées "dans la rangée" du moins dans MySQL.

Quoi qu'il en soit, c'est à vous pour déterminer quelles sont les exigences et les contraintes de votre application, et faire le meilleur choix en fonction de ces informations.