i avoir un jeu de données strong> qui ressemble à ceci: Column1 (PK) | FusionedAttributes
1 | Name = Carl, Jobtitle = Driver
2 | Name = Lisa, Age = 15
3 | Name = Jon, Age = 43, Jobtitle = Programmer
3 Réponses :
Vous ne pouvez pas faire cela efficacement, mais vous pouvez faire:
select c.id,
stuff( (select concat(', ', attribute, ' = ', value)
from t t2
where t2.id = c.id
for xml path(''), type).value('.', 'nvarchar(max)')
), 1, 2, ''
) as FusionedAttributes
from (select distinct column1 from t) c;
CREATE table foo (
id int,
attribute varchar(20),
value varchar(20)
)
INSERT into foo
VALUES
(1,'Name', 'Carl'),
(1,'Jobtitle', 'Driver'),
(2,'Name', 'Lisa'),
(2,'Age', '15'),
(3,'Name', 'Jon'),
(3,'Age', '43'),
(3,'Jobtitle ', 'Programmer')
SELECT e.id, STUFF((SELECT ', ' + attribute+'='+value
FROM foo EE
WHERE EE.id=E.id
FOR XML PATH('')), 1, 1, '') AS listStr
FROM foo E
GROUP BY E.id
SQL Server peut renvoyer les données comme XML complexe depuis 2005. SQL Server 2016 a ajouté le support JSON. Le retour des données de l'un de ces formulaires facilitera la tâche des applications clients de travailler avec elle sans créer leur propre analyseur. Cela permettrait également d'utiliser les valeurs dans d'autres requêtes T-SQL.
Compte tenu de ce tableau: Vous pouvez récupérer les attributs comme xml avec: Ce retour: < / p>
J'ai finalement pris votre réponse car il semble que ce soit le plus pratique pour moi :) Merci d'avoir répondu et de me conduire à une façon de préférer cette notation KV ... Votre commentaire sur l'évitant EAV doit être évalué à coup sûr
@Mayen Vous devriez vérifier les différents articles de SQL Server MVPS à propos de celui-ci par exemple SQL: Conception - Attribut d'entité Tables de valeur (partie 1) - Pourquoi? par greg bas et SQL: Design - Attribut d'entité Tables de valeur (Partie 2) - Avantages et contre . Astuce: ils ne l'aiment pas
Je vais. C'est bien, mais les structures de données qui portent déjà des données sont souvent compliquées à la restructuration. Si des goulots d'étranglement de la performance, quelque chose d'autre doit être trouvé cependant. La requête que vous avez créée donne les résultats requis, mais ils sont énormes ^^
@mayen c'est un problème inhérent de travailler avec EAV. Le seul moyen de pas produire d'énormes résultats est de lire les données de leur forme EAV et de réhydrater les objets du client. Dans SQL Server 2016, vous pouvez utiliser JSON qui produira des résultats légèrement plus grands que ce que vous avez essayé, bien qu'ils semblent laids. La fonction de colonnes SQL Server's Spesse Colums supprime la nécessité d'EAV dans la plupart des cas - pourquoi utiliser EAV quand vous pouvez avoir 30 km de colonnes par table? Internationalement, les valeurs sont stockées dans un champ XML, vous ne payez que des valeurs non nulles
SQL Server peut renvoyer les données comme XML complexe depuis 2005. SQL Server 2016 a ajouté le support JSON. Avez-vous vraiment vouloir renvoyer les données dans ce formulaire? JSON ou XML en feraient beaucoup plus facile pour les clients de travailler avec ces données. Cela faciliterait également la question des données d'attribut / valeur.
En tout cas, vous ne devez probablement pas utiliser un tel schéma EAV. Les colonnes de stockage de SQL Server et le stockage XML / JSON de Server Vous pouvez avoir des milliers de lignes facultatives par table sans prendre de place ou stocker des objets de valeur complexes dans les champs. Un schéma EAV ne peut pas être indexé ou validé