Comment modéliser un champ pouvant contenir à la fois des valeurs numériques et des valeurs de chaîne dans SQL Server 2005?

Question

J'ai une nouvelle table de base de données que j'ai besoin de créer ...
Il contient logiquement un ID, un name et un "value".
Ce champ de valeur peut être numérique ou une chaîne de caractères dans la nature.

Je ne pense pas que je veux juste faire un champ varchar, parce que je veux aussi pouvoir interroger avec des filtres comme WHERE value > 0.5 et autres.

Quelle est la meilleure façon de modéliser ce concept dans SQL Server 2005?

EDIT: Je ne suis pas opposé à la création de plusieurs champs ici (un pour les numéros, l'un pour les non-chiffres), mais comme ils sont tous vraiment le même concept, je ne savais pas que c'était un bonne idée.
Je suppose que je pourrais créer des champs séparés, puis avoir une vue qui les fusionne en une seule colonne logique.

Tous les avis sur cette question?

Ce que je veux réaliser est vraiment assez simple ... habituellement ces données sera simplement aveuglément affiché dans une vue de type grille.
Je souhaite également pouvoir filtrer les valeurs numériques de cette grille. Cette table finira par être dans les dizaines de millions d'enregistrements, donc je ne veux pas me peindre dans un coin avec des performances d'interrogation.
Cette question de performance est ma principale préoccupation.

Answer 1

Votre problème avec le mélange de données peut être de savoir comment Sql 2005 trie les données de texte. Ce n'est pas un genre "naturel".

Si vous avez un champ varchar et vous:

where value > '20.5' 

valeurs comme « 5 » sera dans votre résultat (comme dans une sorte à base de caractère « 5 » vient après « 20,5 »)

Vous allez être mieux avec des colonnes séparées pour le stockage.

Utilisez confluer pour les fusionner en une seule colonne si vous avez besoin de les fusionner dans vos résultats:

select [ID], [Name], Coalesce([value_str], [value_num]) 
from [tablename] 

Answer 2

Si vous souhaitez stocker des valeurs numériques et de chaîne dans la même colonne, je ne suis pas sûr que vous pouvez éviter de faire beaucoup de moulages et convertit en utilisant cette colonne comme un filtre de requête.

Answer 3

Une bonne façon d'obtenir le soutien de la requête que vous voulez est d'avoir deux colonnes: numvalue qui stocke un nombre et textValue qui stocke des caractères. Ils devraient être nullable ou au moins avoir une valeur par défaut qui ne représente aucune valeur. Votre application peut alors décider quelle colonne stocker sa valeur et laquelle laisser sans valeur.

Answer 4

deux colonnes.

Table: (ValueLable as char(x), Value as numerica(p,s)) 

Answer 5

Je ne pense pas qu'il soit possible d'avoir une colonne avec les types varchar et int. Vous pouvez enregistrer votre valeur en tant que varchar et la convertir en int pendant votre requête. Mais de cette façon, vous pourriez obtenir une exception si votre valeur contient un caractère quelconque. Qu'essayez-vous d'accomplir?

Answer 6

Si vous voulez qu'il soit capable de contenir une chaîne de caractères, je pense que vous devez faire la colonne varchar, ou similaire.

Une autre solution pourrait consister à avoir 2 ou 3 colonnes au lieu de la colonne une valeur. Peut-être avoir les trois colonnes, value_type (enum entre "number" et "string"), number_value, string_value. Ensuite, vous pouvez reconstruire cette requête à

WHERE value_type = 'number' AND number_value > 0.5 

Answer 7

Je ne pense pas que vous allez être en mesure de se déplacer en utilisant comme type de données VARCHAR ou NVARCHAR. Avec les données mixtes comme vous le décrivez, vous devrez tester la valeur lorsque vous extrayez le champ de la base de données et que vous effectuez le CAST ou le CONVERT approprié en fonction du type de données.

Answer 8

Je suppose que je pourrais créer des champs séparés, alors une vue ce genre d'entre eux se fond en une seule colonne logique. Des opinions à ce sujet?

Cela dépend de la source des données. Si vous obtenez des données provenant d'utilisateurs (ou d'un autre système) de manière libre et que vous ne vous souciez pas du type de données, la meilleure façon de les stocker est la plus générique (varchar, etc.) . Si les données entrantes sont plus structurées et que vous vous souciez de cette structure, il est plus logique de conserver cette structure dans la base de données en utilisant des champs séparés.

Du point de vue d'un SELECT, cela n'a pas vraiment d'importance; Vous pouvez le stocker dans les deux sens et le lire comme le même schéma. Une fois que vous entrez dans les filtres (comme vous le mentionnez), les choses deviennent un peu plus poilues, mais facilement réalisables. Cependant, vous ne mentionnez pas si vous devez être en mesure de mettre à jour ces données et si c'est le cas, si vous devez appliquer une validation sur les données. Du son, vous devez effectuer différents types de recherches en fonction du «type» de valeur stockée. En tant que tel, il peut être judicieux d'ajouter un champ Type afin que tous les filtres puissent être rapidement limités au type de valeurs qui vous intéresse. Note, par Type je veux dire une portée plus logique, Application, Type; pas le type de données réel étant stocké. Ma recommandation serait d'utiliser un seul champ avec une colonne Type si vous avez besoin de facilement prendre en charge UPDATEs ou utiliser plusieurs champs (ou tables, si ce sont des ensembles de données totalement différents) si SELECT et le filtrage est tout ce qui est nécessaire.

Answer 9

Vous pouvez utiliser deux colonnes, une "chaîne" et une "numérique" (quelles que soient les variantes appropriées) avec la colonne "chaîne" NOT NULL et la colonne "numérique" autorisant les valeurs NULL. Lorsque vous insérez une valeur, remplissez toujours la colonne "chaîne" indépendamment du type, mais si la valeur est numérique, stockez-la également dans la colonne "numérique". Maintenant vous avez un indicateur intégré quant au type (si la colonne "numérique" est remplie, c'est numérique, sinon c'est une chaîne), vous pouvez toujours simplement tirer la valeur pour l'affichage de la colonne "chaîne", et vous pouvez utiliser la valeur "numérique" dans les calculs ou pour un tri/une comparaison numérique approprié selon les besoins. Vous pouvez toujours ajouter une troisième colonne indiquant le type de valeur, mais cette approche élimine le besoin de cela. Notez que vous pouvez envisager de conserver les valeurs numériques et de chaîne à l'aide d'un ensemble de déclencheurs INSERT et UPDATE.