Contexte: SQL Server 2008, C #
J'ai un tableau d'entiers (0-10 éléments). Les données ne changent pas souvent, mais sont souvent récupérées.
Je pourrais créer une table séparée pour stocker les chiffres, mais pour une raison quelconque, il semble que ce ne serait pas optimal.
Question # 1: Dois-je stocker mon tableau dans une table séparée? Veuillez indiquer les raisons d'une manière ou d'une autre.
Question # 2: (quelle que soit la réponse à Q # 1), quelle est la "meilleure" façon de stocker int [] dans le champ de la base de données? XML? JSON? CSV?
EDIT: Quelques informations de base: les nombres stockés ne sont que des coefficients qui ne participent à aucune relation et sont toujours utilisés comme un tableau (c'est-à-dire qu'aucune valeur n'est récupérée ou utilisée de manière isolée).
La "meilleure" façon de stocker des données dans une base de données est la manière la plus propice aux opérations qui y seront effectuées et celle qui facilite la maintenance. C'est cette exigence ultérieure qui devrait vous conduire à une solution normalisée qui signifie stocker les entiers dans une table avec une relation. En plus d'être plus facile à mettre à jour, il est plus facile pour le prochain développeur qui vient après vous de comprendre quoi et comment les informations sont stockées.
Table séparée, normalisée
Pas comme XML ou json, mais des nombres séparés sur des lignes séparées
Peu importe ce que vous pensez, c'est la meilleure façon. Tu peux me remercier plus tard
Stockez-le en tant que tableau JSON mais sachez que tous les accès seront désormais pour l'ensemble du tableau - aucune lecture/écriture individuelle dans des coefficients spécifiques.
Dans notre cas, nous les stockons en tant que tableau json. Comme dans votre cas, il n'y a pas de relation entre les numéros de tableau individuels - le tableau n'a de sens qu'en tant qu'unité et en tant qu'unité, il a une relation avec les autres colonnes du tableau. Soit dit en passant, tout le reste IS normalisé. Je le compare à ceci: si vous deviez stocker un morceau de 10 octets, vous l'enverriez emballé dans une seule colonne de VARBINARY (10) . Vous ne le diviseriez pas en 10 octets, vous les stockeriez dans une colonne de VARBINARY (1) et vous les assembleriez ensuite avec une clé étrangère. Je veux dire que vous pourriez - mais cela n'aurait aucun sens.
VOUS, en tant que développeur, devrez comprendre à quel point ce tableau d'intels est réellement "monolithique".
Un tableau séparé serait la façon la plus "normalisée" de procéder. Et c'est mieux à long terme, probablement, car vous n'aurez pas à analyser la valeur de la colonne pour extraire chaque entier.
Si vous le souhaitez, vous pouvez également utiliser une colonne XML pour stocker les données.
Colonnes éparses peut également être une autre option pour vous.
Si vous voulez que ce soit vraiment simple, vous pouvez simplement délimiter les valeurs: 10;2;44;1
Je pense que puisque vous parlez de serveur SQL, cela indique que votre application peut être une application pilotée par les données. Si tel est le cas, je garderais définitivement le tableau dans la base de données comme une table séparée avec un enregistrement pour chaque valeur. Il sera normalisé et optimisé pour la récupération. Même si vous n'avez que quelques valeurs dans le tableau, vous devrez peut-être combiner ces données avec d'autres données récupérées qui devront peut-être être "jointes" à vos valeurs de tableau. Dans ce cas, sql est optimisé en utilisant des index, des clés étrangères, etc. (normalisé).
Cela étant dit, vous pouvez toujours coder en dur les 10 valeurs de votre code et enregistrer l'aller-retour dans la base de données si vous n'avez pas besoin de modifier les valeurs. Cela dépend du fonctionnement de votre application et de l'utilisation de ce tableau.
Je suis d'accord avec tous les autres sur le meilleur étant une table normalisée séparée. Mais si vous insistez pour que tout soit dans la même table, ne placez pas le tableau dans une seule colonne. À la place, créez les 10 colonnes et stockez chaque valeur de tableau dans une colonne différente. Cela vous évitera les problèmes d'analyse et de mise à jour.