Tout d'abord, vous ne voulez vraiment pas faire ça. Une colonne dans un SGBDR est censée être atomique, en ce sens qu'elle contient une et une seule information. Essayer de stocker plus d'un élément de données dans une colonne est une violation de la première forme normale.
Si vous devez absolument le faire, vous devez convertir les données sous une forme pouvant être stockée sous la forme d'un seul élément de données, généralement une chaîne. Vous pouvez utiliser le mécanisme PHP serialize(), l'analyse XML (si les données se trouvent être une arborescence de documents), json_encode(), etc.
Mais comment interroger efficacement ces données ? La réponse est que vous ne pouvez pas.
De plus, si quelqu'un d'autre prend en charge votre projet ultérieurement, vous allez vraiment l'ennuyer, car les données sérialisées dans une base de données sont horribles à utiliser. Je le sais parce que j'ai hérité de tels projets.
Ai-je mentionné que vous ne voulez vraiment pas faire ça ? Vous devez repenser votre conception afin qu'elle puisse être stockée plus facilement en termes de lignes atomiques. Utilisez une autre table pour ces données, par exemple, et utilisez des clés étrangères pour les lier à l'enregistrement maître. On les appelle des bases de données relationnelles pour une raison.
MISE À JOUR :On m'a posé des questions sur les exigences de stockage de données, par exemple si une seule ligne serait moins chère en termes de stockage. La réponse est, dans les cas typiques, non, ce n'est pas le cas, et dans les cas où la réponse est oui, le prix que vous payez ne vaut pas la peine d'être payé.
Si vous utilisez une table dépendante à 2 colonnes (1 colonne pour la clé étrangère de l'enregistrement auquel appartient l'échantillon, une pour un seul échantillon), chaque colonne nécessitera au pire 16 octets (8 octets pour une colonne de clé longint, 8 octets pour un nombre à virgule flottante double précision). Pour 100 enregistrements, cela représente 1 600 octets (en ignorant la surcharge de la base de données).
Pour une chaîne sérialisée, vous stockez dans le meilleur des cas 1 octet par caractère dans la chaîne. Vous ne pouvez pas savoir combien de temps va durer la chaîne, mais si nous supposons que 100 échantillons avec toutes les données stockées par une coïncidence artificielle se situent tous entre 10000,00 et 99999,99 avec seulement 2 chiffres après la virgule décimale, alors vous ' re regardant 8 octets par échantillon. Dans ce cas, tout ce que vous avez économisé est la surcharge des clés étrangères, de sorte que la quantité de stockage requise est de 800 octets.
Cela repose bien sûr sur de nombreuses hypothèses, telles que l'encodage des caractères étant toujours de 1 octet par caractère, les chaînes qui composent les échantillons ne dépassant jamais 8 caractères, etc.
Mais bien sûr, il y a aussi la surcharge du mécanisme que vous utilisez pour sérialiser les données. La méthode la plus simple absolue, CSV, consiste à ajouter une virgule entre chaque échantillon. Cela ajoute n-1 octets à la chaîne stockée. Ainsi, l'exemple ci-dessus serait maintenant de 899 octets, et c'est avec le schéma de codage le plus simple. Les sérialisations JSON, XML et même PHP ajoutent toutes plus de caractères supplémentaires que cela, et vous aurez bientôt des chaînes beaucoup plus longues que 1600 octets. Et tout cela est avec l'hypothèse d'un codage de caractères de 1 octet.
Si vous avez besoin d'indexer les échantillons, les besoins en données augmenteront de manière encore plus disproportionnée par rapport aux chaînes, car un index de chaîne est beaucoup plus coûteux en termes de stockage qu'un index de colonne à virgule flottante.
Et bien sûr, si vos échantillons commencent à ajouter plus de chiffres, le stockage de données augmente encore. 39281.3392810 ne sera pas stockable en 8 octets sous forme de chaîne, même dans le meilleur des cas.
Et si les données sont sérialisées, la base de données ne peut pas les manipuler. Vous ne pouvez pas trier les échantillons, faire des opérations mathématiques sur eux, la base de données ne sait même pas que ce sont des nombres !
Pour être honnête, le stockage est ridiculement bon marché de nos jours, vous pouvez acheter plusieurs disques TB pour de petites sommes. Le stockage est-il vraiment si critique ? À moins que vous n'ayez des centaines de millions d'enregistrements, je doute que ce soit le cas.
Vous voudrez peut-être consulter un livre intitulé SQL Antipatterns
