Quelle est la fraîcheur des types de données définis par l'utilisateur dans SQL Server? [fermé]

Question

Les types de données définis par l'utilisateur dans SQL Server doivent-ils être connus et utilisés par un utilisateur intermédiaire de SQL?

Quels sont les avantages et les inconvénients de l’utilisation des UDT?

Answer 1

Ne les utilisez jamais est mon conseil. Vous êtes dans un monde de souffrance si vous devez jamais changer la définition. Cela s’est peut-être amélioré depuis SQL Server 2000 et une personne plus familiarisée avec les versions les plus récentes peut vous dire si vous pouvez maintenant vous mettre à l’eau sans risque, mais tant que je n’aurais pas confirmation et que j’ai vérifié moi-même avec un test, je ne ne le mettez pas sur mon système de production.

Consultez cette question pour plus de détails: Comment modifier le type de base d'un type défini par l'utilisateur dans SQL Server 2005?

Answer 2

Je n’utilise pas les UDT basés sur du code car je ne pense pas que la complexité supplémentaire justifie les avantages. Je utilise des UDT T-SQL car il n’ya que très peu de complexité supplémentaire et que les avantages en valent la peine. (Merci à Marc_s d’avoir signalé que mon message original était incomplet!)

À propos des UDT basés sur du code

Pensez-y de cette façon: si votre projet comporte un composant de code managé (votre application) et un composant de base de données (SQL Server), quel avantage réel retirez-vous de la définition de code managé dans la base de données? Dans mon expérience? Aucun.

Le déploiement est plus difficile car vous devez ajouter des assemblys à votre déploiement de base de données et les modifier, ajouter des fichiers, etc. dans SQL Server. Vous devrez également activer le CLR dans SQL Server (ce n'est pas grave, mais personne ne m'a prouvé que cela ne serait pas pénalisant en termes de performances / mémoire). En fin de compte, vous aurez exactement ce que vous auriez eu si vous aviez simplement intégré cela dans le code de votre application. Il peut y avoir une amélioration des performances, mais cela me semble être un cas d’optimisation prématurée, d’autant plus que je ne sais pas si la performance globale en souffre du fait que le CLR est activé ou désactivé.

Remarque: je suppose que vous utiliseriez le CLR de SQL Server pour définir vos types. HLGEM parle de SQL Server 2000 mais je ne suis pas familier avec 2000 et pensais qu'il ne contenait que des fichiers UDF et non des fichiers UDT dans des dll définies de manière externe (mais ne me citez pas ... je ne le connais pas vraiment!).

À propos des UDT T-SQL

Les UDT T_SQL peuvent être définis dans SQL seul (voir "Programmabilité | Types | Types de données définis par l'utilisateur" dans SQL Server Management Studio). Pour les UDT standard, je recommanderais de les maîtriser. Elles sont assez simples et peuvent rendre votre DDL plus auto-documentée et peuvent imposer des contraintes d’intégrité. Par exemple, je définis un " GenderType " (caractère (1), non nullable, contenant "M" ou "F") qui garantit que seules les données appropriées sont autorisées dans le champ Sexe.

Les UDT sont plutôt simples dans l’ensemble, mais cet article en donne un très bon exemple. comment passer au niveau supérieur en définissant une règle pour contraindre les données autorisées dans votre UDT.

Lorsque j’ai répondu à cette question à l’origine, je me suis concentré sur l’idée des types complexes définis par le code ( sent la paume sur le front ). Alors ... merci Marc.

Answer 3

Le pro des types définis par l'utilisateur est bien traité

Je voudrais également signaler que la fonction sp_bindrule est obsolète, comme indiqué dans le message d'Alex. Je ne sais pas quand il a été déconseillé, mais c'est maintenant. En fait, les règles sont obsolètes dans leur ensemble.

Si je voulais créer un type avec une restriction, j'envisagerais d'utiliser un type de table défini par l'utilisateur avec une contrainte de vérification sur la ou les colonnes appropriées. Cela me permet également de construire un type de données complexe.

Answer 4

Je ne peux pas vraiment vous recommander l’utilisation de fonctionnalités spécifiques à l’implémentation SQL qui rendraient la tâche plus difficile lorsque vous développez mssql et que vous migrez vers un autre dbms. Pour notre dwh dbs, nous avons démarré le mssql, émigré en oracle et depuis l’année dernière, nous sommes passés au hp vertica.