SQL 2008: Utilisation de tables séparées pour chaque type de données afin de renvoyer une seule ligne

Question

Je pensais que je serais flexible cette fois-ci et que je laisserais les utilisateurs décider des informations de contact qu'ils souhaitent stocker dans leur base de données. En théorie, il ressemblerait à une seule ligne contenant, par exemple; nom, adresse, code postal, Catégorie X, A. éléments de la liste

Exemple
FieldType table définissant les types de données disponibles à un utilisateur:

FieldTypeID, FieldTypeName, TableName 
1,"Integer","tblContactInt" 
2,"String50","tblContactStr50" 
... 

Un utilisateur le définit ses champs dans le FieldDefinition tableau:

FieldDefinitionID, FieldTypeID, FieldDefinitionName 
11,2,"Name" 
12,2,"Address" 
13,1,"Age" 

Enfin nous stockons le réel contacter les données dans des tableaux séparés en fonction de son type de données. table principale, ne contient que le ContactID

tblContact:

ContactID 
21 
22 

tblContactStr50:

ContactStr50ID,ContactID,FieldDefinitionID,ContactStr50Value 
31,21,11,"Person A" 
32,21,12,"Address of person A" 
33,22,11,"Person B" 

tblContactInt:

ContactIntID,ContactID,FieldDefinitionID,ContactIntValue 
41,22,13,27 

Question: Est-il possible de retourner le contenu de ces tables en deux rangées comme ceci:

ContactID,Name,Address,Age 
21,"Person A","Address of person A",NULL 
22,"Person B",NULL,27 

J'ai regardé en utilisant les tables de COALESCE et Temp, se demandant si cela est possible. Même si c'est le cas: peut-être que je ne fais qu'ajouter de la complexité tout en sacrifiant les performances pour le bénéfice de l'option de datastorage et de définition de l'utilisateur.

Qu'en pensez-vous?

Answer 1

Je ne pense pas que ce soit une bonne façon d'aller parce que:

• Un insert simple 1 record pour un contact devient soudainement inserts n. par exemple. si vous stockez les données varchar, nvarchar, int, bit, datetime, smallint et tinyint pour un contact, c'est 7 insertions dans les tables spécifiques au type de données, +1 pour l'enregistrement d'en-tête principal
• De même, une requête référencera automatiquement 7 tables, avec 6 JOINs impliqués juste pour obtenir tous les détails

Personnellement, je pense qu'il est préférable d'opter pour une approche moins "générique". Rester simple.

Mise à jour: La question est, avez-vous vraiment besoin d'une solution flexible comme celle-ci? Pour les données de contact, vous devez toujours être en mesure de stocker au moins un ensemble de champs de base (ligne d'adresse 1-n, prénom, nom de famille, etc.). Si vous avez besoin d'un moyen pour l'utilisateur de stocker des données personnalisées/définissables par l'utilisateur au-dessus de cet ensemble de données standard, c'est une exigence courante.Diverses options comprennent:

• colonne XML dans votre table principale Contacts pour stocker tous les utilisateurs des données définies
• 1 table supplémentaire contenant des données de paires clé-valeur un peu comme vous avez parlé à l'origine au sujet, mais à bien moindre degré! Cela contiendrait la clé du contact, le nom de l'élément de données personnalisé et la valeur.

Celles-ci ont déjà été discutées ici sur SO donc cela vaudrait la peine de creuser autour de cette question. Je n'arrive pas à trouver la question dont je me souviens après un coup d'œil rapide!

certains qui traitent trouvé les avantages/inconvénients de l'approche clé-valeur, pour sauver le répéter:
Key value pairs in relational database
Key/Value pairs in a database table