Meilleure façon de stocker le champ de type muti

Disons que nous avons un champ qui peut être de plusieurs types, par exemple: chaîne de caractères ou date ou types de données XML.Meilleure façon de stocker le champ de type muti

Maintenant, nous avons deux méthodes pour le stocker dans une base de données

1- en utilisant un champ typé string + Type de définition de champ: perte "de type-aware" capacités de tri, il a besoin coulée

2- tables séparées (StringValues, DateValues, Decimal, XML ... etc): une clé étrangère pointant vers une valeur + champ définissant le type: en quelque sorte compliqué, performance

la seconde méthode peut avoir un avantage supplémentaire si seulement des valeurs uniques ont été stockées: fonctionnera comme un index.

Avez-vous quelque chose en tête?

Note1: De préférence, pensez projet basé sur MS SQL Server 2008 et Linq2SQL

Note2: Peut-être que nous allons discuter de la façon de mettre en œuvre EAV dans une autre question, je pose la question au sujet EAV dans un stockage relationnel.

Note3: Les types peuvent changer, mais pas souvent

Source

2009-08-27 Ahmed Khalaf

Vous ne perdez pas les capacités de tri avec le type définissant le champ si vous utilisez cast et le tri par le type casted. Cela ressemble à la seconde méthode, c'est ce que vous voulez. –

mais ting n'est pas entièrement supporté par SqlServer, sera-t-il efficace pour lancer et trier du côté du code? –

Je ne suis pas sûr que ce soit assez de détails pour bien répondre à la question. Si vous demandez littéralement à propos du cas de deux types, vous pouvez également considérer une table avec une colonne pour chaque type et un discriminateur. La "bonne" réponse peut dépendre de spécificités telles que le nombre de types distincts à supporter, la vitesse par rapport aux contraintes d'espace, etc.

Certains pourraient arguer que l'approche la moins coûteuse est la meilleure. Plus précisément, l'approche qui selon vous nécessitera le moins de coûts à comprendre et à maintenir (souvent ~ 60% du coût total de possession).

En ce qui concerne tous les conseils de ne pas le faire, je suis d'accord si possible. D'un autre côté, SharePoint est un exemple qui montre que ce n'est pas impossible. Bonne chance!

Source

2009-09-22 02:16:09

On dirait que vous concevez une solution EAV, où vos valeurs stocke de table pour plusieurs attributs, une valeur par ligne.

EAV est une conception non relationnelle. Il n'y a pas de "bonne" façon de le faire en ce qui concerne la bonne rules of relational database design.

La conception appropriée consiste à stocker chaque attribut dans une colonne distincte de un tableau. Donnez à chaque colonne le bon type de données et un nom descriptif. Ne stocker que les valeurs du même type logique dans chaque colonne. Si vous avez besoin d'attributs dynamiques, utilisez non-relational data management solution.

Source

2009-08-27 22:53:05

Je n'aurais pas pu dire mieux moi-même! –

Je sais que ce n'est pas en suivant les directives de normalisation, mais je demande quel est le meilleur moyen d'y arriver avec le moins de sacrifices. –

Vous sacrifiez virtuellement * chaque * avantage d'une base de données relationnelle lorsque vous utilisez la conception EAV, donc vous pouvez aussi bien ne pas utiliser une base de données relationnelle. –

Je voudrais aller avec la deuxième option et cacher la complexité de la situation de la table avec quelques vues. De cette façon, une fois que vous aurez plus de flexibilité, vos applications pourront toujours pointer vers les vues sans avoir besoin d'être modifiées et vous pourrez réorganiser vos tables sous-jacentes en quelque chose de plus propre.

Source

2009-09-22 02:25:41

Pouvez-vous envisager d'utiliser un type de données XML? Si c'est le cas, vous pouvez utiliser un attribut/élément pour définir le type.

<string>My string value</string> 
<date>24-Nov-1976</date>

Ou,

<val type="System.String">My string value</val> 
<val type="System.Date">24-Nov-1976</val>

SQL Server 2005+ a un bon support pour l'indexation XML qui peut répondre à vos besoins. D'un point de vue Linq to SQL, vous pouvez probablement avoir une classe légère qui peut mapper les types à un type de données spécifique; XML de/sérialisation peut être une option ici.

Source

2009-09-22 02:43:34

qu'en est-il des performances? si j'ai besoin d'interroger sur les valeurs ... –

aussi l'indexation n'est pas très efficace –

Interrogation sur les types de données XMl ressemble à ceci: SELECT xCol FROM docs où xCol.exist ('/ book/@ ISBN [. = "0-2016 -3361-2 "] ') = 1 Je n'ai pas de détails sur les performances de l'indexation XML. Je pense que cela dépend si vous tapez votre XML. Bien sûr, selon le scénario, ce coût de performance peut être acceptable. Vous saurez seulement si vous essayez l'analyse comparative. –

Si le nombre de types possibles est faible, utilisez l'option 2 (tables supplémentaires + clé étrangère) ou utiliser l'option 3.

Option 3: Utilisez une table avec un champ de chaque type et un ENUM champ définissant quel champ est pertinent.

Si le nombre de types possibles est grande ou non constante, utilisez l'option 1 (chaînes) - vous pouvez stocker les dates dans les chaînes AAAA-MM-JJ-HH-MM-SS pour préserver le tri.

Source

2009-09-23 21:15:41

Meilleure façon de stocker le champ de type muti

Répondre

Questions connexes