Les UDT CLR sont-ils couramment utilisés dans les applications d'entreprise?

Question

J'examine certaines des technologies les plus récentes disponibles dans SQL Server 2005/2008. La plupart de mes applications sont écrites en C # et comportent généralement un composant base de données. La plupart de ce que je trouve sur Google sont les suivants: "Voici comment vous configurez un UDT CLR". J'ai quelques questions d'ordre général sur leur application et leur utilisation dans le monde réel.

• Les UDT hébergés par CLR sont-ils couramment utilisés dans les applications? Grande ou petite échelle
• Existe-t-il des problèmes de performances liés à leur utilisation?
• Les administrateurs de base de données préfèrent-ils uniquement utiliser les types intégrés?

Ils semblent être un moyen de simplement mettre un objet dans une table. Ai-je raison de supposer que l'éventail actuel des problèmes pour lesquels les solutions sont simplifiées du fait de leur utilisation est minime?

Answer 1

Les UDT ne présentent un avantage que lorsqu'ils représentent véritablement un élément fondamental de votre application. Presque toujours, ils peuvent être décomposés en types construits, mais l'avantage est que vous n'avez pas à convertir l'objet renvoyé. Par conséquent, vous ne devriez probablement pas utiliser de types UDT représentant des objets complexes tels que Employee, mais quelque chose de fondamental, comme Size ou Location, pourrait constituer un bon choix, car il est léger mais très rigide dans sa définition.

Answer 2

J'ai enquêté sur leur utilisation, mais je suis devenu mal à l'aise face à la gestion des versions. Que se passe-t-il si vous téléchargez une version plus récente de l'assembly sur le serveur? En raison des dépendances, vous devrez abandonner l'UDT et le recréer, mais qu'adviendra-t-il alors des données? Nous nous en tenons aux types intégrés.