Pour répondre :le texte est obsolète dans de nombreux SGBD, il est donc préférable d'utiliser un blob ou un varchar avec une limite élevée (et avec blob, vous n'aurez aucun problème d'encodage, ce qui est un problème majeur avec varchar et texte) .
Également comme indiqué dans ce fil sur les forums MySQL , les disques durs sont moins chers que les logiciels, vous feriez donc mieux de concevoir d'abord votre logiciel et de le faire fonctionner, et seulement ensuite si l'espace devient un problème, vous voudrez peut-être optimiser cet aspect. N'essayez donc pas de trop optimiser la taille de votre colonne trop tôt, mieux vaut définir une taille plus grande au début (en plus, cela évitera les problèmes de sécurité).
A propos des différents commentaires :Trop de fanatisme SQL ici. Malgré le fait que j'aime beaucoup SQL et les modèles relationnels, ils ont aussi leurs pièges.
Le stockage de données sérialisées dans la base de données telles quelles (comme le stockage de données au format JSON ou XML) présente quelques avantages :
- Vous pouvez avoir un format plus flexible pour vos données :ajouter et supprimer des champs à la volée, modifier la spécification des champs à la volée, etc...
- Moins de décalage d'impédance avec le modèle d'objet :vous stockez et vous récupérez les données telles qu'elles sont dans votre programme, par rapport à la récupération des données, puis à leur traitement et conversion entre les structures des objets de votre programme et les structures de votre base de données relationnelle .
Et il y a beaucoup d'autres avantages, alors s'il vous plaît, pas de fanboyisme :les bases de données relationnelles sont un excellent outil, mais n'abusons pas des autres outils que nous pouvons obtenir. Plus d'outils, mieux c'est.
Comme exemple concret d'utilisation, j'ai tendance à ajouter un champ JSON dans ma base de données pour stocker des paramètres supplémentaires d'un enregistrement où les colonnes (propriétés) des données JSON ne seront jamais SELECT'd individuellement, mais uniquement utilisées lorsque le bon enregistrement est déjà sélectionné. Dans ce cas, je peux toujours discriminer mes enregistrements avec les colonnes relationnelles, et lorsque le bon enregistrement est sélectionné, je peux simplement utiliser les paramètres supplémentaires pour le but que je veux.
Donc, mon conseil pour conserver le meilleur des deux mondes (vitesse, sérialisabilité et flexibilité structurelle), utilisez simplement quelques colonnes relationnelles standard pour servir de clés uniques pour faire la distinction entre vos lignes, puis utilisez une colonne blob/varchar où vos données sérialisées seront être inséré. Habituellement, seules deux ou trois colonnes sont requises pour une clé unique, ce ne sera donc pas une surcharge majeure.
De plus, vous pourriez être intéressé par PostgreSQL qui a maintenant un type de données JSON, et le projet PostSQL pour traiter directement les champs JSON comme des colonnes relationnelles.
