Sont-types de données SQL définies par l'utilisateur utilisé beaucoup? [fermé]

Question

Mon DBA m'a dit d'utiliser un type de données SQL défini par l'utilisateur pour représenter les adresses, puis utiliser une seule colonne de ce nouveau type dans notre table d'utilisateurs au lieu de colonnes d'adresses multiples. Je ne l'ai jamais fait ça avant et je me demande si cela est une approche commune.

En outre, quel est le meilleur endroit pour obtenir des informations sur ce - est-il spécifique au produit

Answer 1

Il y a un certain nombre d'autres questions sur SO sur la façon de représenter les adresses dans une base de données. AFAICR, aucun d'entre eux suggèrent un type défini par l'utilisateur dans le but. Je ne considère pas comme une approche commune; cela ne veut pas dire que ce n'est pas une approche raisonnable. Les principales difficultés se situent dans le choix des méthodes pour fournir de manipuler les données d'adresse - celles utilisées pour le formatage des données apparaissent sur une enveloppe, ou dans des endroits spécifiques sur un formulaire, ou à mettre à jour les champs, se soucier des nombreuses ramifications d'adresses internationales et ainsi de suite.

Définition des types définis par l'utilisateur est spécifique très produit. Les moyens que vous faites dans Informix sont différentes de la manière dont elle se fait dans DB2 et Oracle, par exemple.

Answer 2

Pour autant que je peux dire, au moins dans le monde SQL Server, UDT ne sont pas utilisés beaucoup.

Problème avec UDT est le fait que vous ne pouvez pas facilement les mettre à jour. Une fois créé et utilisé dans les bases de données, ils sont presque comme gravées dans le marbre.

Il n'y a pas « CREATE OR ALTER (UDT) » commande :-( Donc, pour changer quelque chose, vous devez faire beaucoup de brassage autour - peut-être copier loin des données existantes, puis laisser tomber beaucoup de colonnes d'autres tables, puis de laisser tomber votre UDT, recréant avec la nouvelle structure et réappliquer les données et tout.

C'est tout simplement trop de problèmes - et vous savez: il y a être changer!

En ce moment, dans la terre SQL Server, UDT sont juste une bonne idée - mais vraiment mal mis en œuvre. Je ne recommanderais pas de les utiliser largement.

Marc

Answer 3

Je voudrais aussi plutôt éviter d'utiliser des types de données définis par l'utilisateur comme leur facilité d'utilisation et defination fera votre code dépendant d'une base de données particulière.

Au lieu de cela, si vous utilisez un langage orienté objet, créer une relation de composition pour définir des adresses pour un employé (par exemple) et stocker les adresses dans un tableau distinct.

Par exemple. table Employés et une table Employee_Addresses. Un employé peut avoir plusieurs adresses.

Answer 4

  

type SQL défini par l'utilisateur pour représenter les adresses

types définis par l'utilisateur peuvent être très utiles, mais une adresse postale ne saute pas comme un de ces cas (pour moi, au moins). Qu'est-ce qu'une adresse postale pour vous? Est-ce quelque chose que vous imprimez sur une enveloppe de poster quelqu'un? Dans ce cas, le texte est à peu près aussi bon que ça va arriver. Si vous avez besoin de savoir ce que quelqu'un est en état pour des raisons juridiques, magasin qui séparément et ce n'est pas un problème.

D'autres messages ici ont critiqué UDT, mais je pense qu'ils ont des utilisations étonnantes. PostgreSQL a la recherche en texte intégral en tant que plug-in basé sur UDT pendant longtemps avant la recherche de texte intégral a été effectivement intégré au produit de base. En ce moment PostGIS est un produit SIG très réussi qui est tout à fait un plug-in basé sur UDT (possède une licence GPL, donc ne sera jamais intégré dans le noyau).