Je souhaite stocker un tableau de valeurs entières dans une table de base de données SQL (SQLServer 2005), si possible en utilisant une seule colonne.Stockage de tableaux de valeurs entières dans SQL Server
Le tableau d'entiers aura une longueur de 7560 valeurs. J'utilise une objectdatasource, le type de données doit être compatible avec les paramètres générés d'un tableadapter.
merci pour aider :)
Vous avez au moins deux choix:
Si vous souhaitez normaliser votre base de données, vous devriez prendre la deuxième option.
@OP, je recommande l'option deux. – Brad
Merci pour votre réponse! Si je normalise la base de données je finirai avec des millions de lignes (peut-être plus de 50 millions). Je ne suis pas sûr si la base de données peut gérer cela sans problèmes de performance. – spoekes
@spoekes: Je pense que vous devez considérer vos cas d'utilisation pour décider quelle solution vous convient le mieux.Avez-vous toujours besoin d'aller chercher et modifier toute la liste en même temps? Ensuite, en utilisant une seule cellule est probablement bien. Voulez-vous parfois modifier un seul élément ou vérifier si un élément est dans une liste? Ensuite, la normalisation vous donnera probablement de meilleures performances. –
Seulement si vous devez! Vous pouvez facilement créer une autre table contenant une clé étrangère dans votre table et une colonne int.
Si vous insistez pour le conserver dans SQL Server en tant que colonne, vous devez utiliser le type de colonne IMAGE ou VARBINARY (MAX) car la longueur de vos données dépasse 8K. Cela va stocker chaque int comme une valeur binaire de 4 octets.
Qu'est-ce que ObjectDataSource?
Merci pour votre réponse! Y a-t-il des inconvénients en utilisant VARBINARY (MAX) ou IMAGE? ObjectDataSource est une couche d'accès aux données qui génère des méthodes pour récupérer des données. – spoekes
La performance des champs VARBINARY (MAX) ou IMAGE n'est pas très bonne bien qu'elle soit suffisante. – Aliostad
Faites-le bien: 1NF ne stipule aucune valeur répétée. Chaque élément de votre tableau de 7560 éléments proposé appartient à sa propre ligne. En plaçant chaque élément dans sa propre rangée, vous donnez au SGBDR une chance de faire des choses qu'il ne peut pas faire autrement, par exemple: calculer des statistiques sur l'ensemble, vérifier que chaque élément adhère aux règles de domaine, calculer les différences entre deux ensembles , compte/sélectionne les ensembles partageant certaines caractéristiques.
Je finirai avec des millions de lignes (peut-être plus de 50 millions). Je ne suis pas sûr si la base de données peut gérer cela sans problèmes de performance.
Ce n'est pas particulièrement important, et vous n'aurez pas besoin de gérer les 50 millions la plupart du temps. Calculez vous-même le nombre d'accès nécessaires pour rechercher un arbre binaire afin de trouver un enregistrement sur un milliard. La réponse pourrait te surprendre.
il n'y a pas besoin de tout réaliser. Pour le marquage, je crois, vous devriez d'abord stocker en tableau, puis, à des fins de performance et de rapport, créer un autre tableau pour faciliter cela. C'est probablement la raison pour laquelle certaines personnes optent pour mongoDB. Mais en fait, c'est parce que les gens disent que vous ne devriez pas faire ceci ou cela qui l'a causé à mon humble avis. – windmaomao
Je le stocke dans la valeur coma séparée si les données ne sont pas liées à une autre table (par exemple, les valeurs que vous souhaitez traiter d'une certaine façon), si elles sont (produits dans une facture, par exemple) une autre table avec une clé étrangère. Pourquoi ne pas simplement créer un grand champ de texte et séparer les valeurs par des virgules?
ou utilisez un blob comme bitmap (4 octets par int), ou bien créez une table avec 7561 champs: P – joni