Comment gérer des données orphelines : table dédiée ou champ JSON ?

[Layla70]

Salut à tous, je suis en train de refondre une petite appli perso et je me retrouve avec un casse-tête sur la structure. J’ai une table "utilisateurs" et une table "commandes", mais pour certaines actions, je dois aussi stocker des préférences temporaires qui n’appartiennent vraiment à aucune des deux. Je me demande si je crée une nouvelle table dédiée pour ces données orphelines, ou si je les ajoute dans un champ JSON dans la table utilisateurs, quitte à avoir des champs parfois vides. Je ne sais pas trop quelle approche serait la plus propre à long terme pour l’évolutivité.

[Ava.J]

Pour moi, créer une table dédiée pour les préférences temporaires garde les données clairement séparées et facilite les évolutions futures. Ça évite d’alourdir la table utilisateurs avec des colonnes qui ne seront pas utilisées par tous les profils et ça permet d’appliquer des index et des contraintes spécifiques. Si ces préférences évoluent ou s’allongent, tu pourras aussi les versionner sans toucher à l’objet principal. Le choix raconte aussi comment tu vois l’ownership des données.

[IsabellaIR]

Dans mon expérience, mettre des données temporaires dans un champ JSON peut dépanner au début, mais ça complique les migrations, les validations et les requêtes qui cherchent ces préférences. Tu te retrouves avec des champs virtuels qui deviennent normaux et qui manquent de traçabilité. Si tu veux de l’évolutivité, mieux vaut une structure explicite pour ces préférences temporaires.

[AndrewRR]

J’avoue que j’aime l’idée de séparer, sinon le tiroir JSON devient un bordel à moitié oublié qui pollue les listes de filtres. Avec une table dédiée, chaque action a une vraie raison d’être et des règles comme des contraintes d’intégrité. Et puis j’aime l’espace dédié pour ces préférences temporaires plutôt que de les traiter comme des secondaires dans le profil.

[AlexanderM]

Sinon tu pourrais aussi envisager un modèle hybride: stocker les données les plus utilisées dans le JSON et garder les éléments plus lourds dans une table séparée. Ça dépend de quel type d’actions utilisent ces préférences et de leur fréquence. Le choix n’est pas uniquement technique, il influence aussi la façon dont les lecteurs imaginent l’appli.

[StellaA]

On dirait que le vrai enjeu n’est pas l’emplacement exact des données mais qui les gère et comment elles évoluent avec le temps. Si l’objectif est d’éviter les champs vides et d’avoir une traçabilité, une table dédiée peut paraître plus naturelle que multiplier les champs optionnels dans utilisateurs. En somme, c’est une question d’ownership des données et des cas d’usage.

[Amelia85]

Tu as déjà un schéma de requêtes qui accédera à ces préférences temporaires et vois-tu l’impact sur les migrations futures ?