Des centaines d'alias / synonymes par rapport aux noms complets des tables de database

Le code (SQL ou proc stocké) doit restr dans un système de gestion de code source en dehors de la database. Si vous ne pouvez pas searchr et replace avec précision, vous avez de sérieux problèmes, alors il faut vraiment y remédier en premier.

Lorsque le nombre de tables est grand, vous devez vraiment utiliser des préfixes. Non Sales.Customer mais REF_Customer.

Le point indique qu'il se trouve dans une database distincte (MS et Sybase) ou un schéma (DB2 et Oracle). C'est une unité de récupération séparée, donc ils sont maintenus séparément, et le server doit changer de context chaque fois que vous traversez la frontière. Par conséquent, vous devez rassembler vos tables correctement dans cet esprit et utiliser quelques bases de données / schémas, pas beaucoup. Par exemple. séparer les tables de reference, qui ne sont pas mises à jour souvent, et sont communément référencées à partir d'autres dbs / schémas.

Utilisez toujours des noms complets dans le code SQL. Pas comme préfixe pour les noms de colonnes, mais dans toutes les clauses WHERE et FROM. Cela aidera grandement lors du déplacement de database / schémas ou des environnements, DEV à UAT ou PROD.

J'utilise toujours des alias dans les requêtes, une raison principale est que la requête est plus facile à lire. Répéter le nom complet de la table encore et encore encombre le code.

La plupart du time, le nom de la table est superflue, il est évident juste à partir du nom du champ d'où ils viennent. Cependant, vous devez toujours spécifier de quelle table vous disposez d'un champ, ce qui rend la requête plus facile à gérer et devient less sensible aux modifications de la database.

Une requête n'utilise généralement que quelques tables, et comme elles sont liées, il est assez facile de garder une trace des tables utilisées. Sinon, ce n'est qu'une autre étape pour déterminer ce que signifie l'alias, et l'information est disponible directement dans la requête.

Si vous devez déplacer une table vers une autre database, les alias sont également utiles. Comme le nom complet de la table n'est spécifié qu'une seule fois dans la requête, il est plus facile de le modifier.

S'il y a une différence de performance entre les différentes façons de spécifier le même champ, cela ne serait que dans le process d'parsing de la requête, ce qui serait minime. Lorsque la requête est en cours d'exécution, il n'y a aucune différence de performance.

C'est une situation "ça dépend".

Personnellement, dans une application avec des tables réparties sur plusieurs schémas, je préférerais ne pas coder en dur les noms de schéma n'importe où dans mon code; à cette fin, je voudrais créer des synonymes privés pour chaque schéma qui a du code.

Ainsi, si une table est déplacée d'un schéma à un autre, ou (pire encore) un schéma est renommé), je n'ai qu'à mettre à jour les synonymes qui pointent dessus, au lieu de parcourir tout le code et toutes les vues.

D'autre part, dans certains cas, j'ai préféré écrire du code qui fait explicitement reference au schéma – c'était le code d'un projet de migration de données qui devait se référer à la même table dans plusieurs schémas, et nous "verrouillions" le schéma noms de sorte qu'il fonctionnerait dans DEV / TEST / etc, sans avoir besoin de beaucoup de synonymes.

Mes deux centimes…

Personnellement, les entresockets sur lesquelles j'ai travaillé ont utilisé des noms d'objects qualifiés, même en reference à des objects du même schéma. Dans les rares cas où nous avons déplacé une table vers un autre schéma, nous avons généralement mis en place une vue (pas un synonyme) dans l'ancien location pour la compatibilité descendante, principalement parce que nous avons été brûlés par des problèmes de revalidation dans le passé.

Du sharepoint vue des performances, au less dans Oracle, les performances sont légèrement affectées par les synonymes, car la database doit d'abord résoudre le nom du synonyme, puis résoudre le nom de l'object cible (table / view / package / etc.). Les synonymes publics ont un impact légèrement supérieur sur les performances (2 fois celui des synonymes non publics). Cependant, ceci est quelque peu contesté; voir cet article Ask Tom pour plus d'informations. Cependant, à less que vous ne poussiez votre database à la limite, je ne m'en soucierais pas.

Si vous prévoyez que les tables vont vraiment bouger, soyez prudent, utilisez des noms complets.

Il y a toujours plus que la réponse à n'importe quelle question. C'est pourquoi "ça dépend" est toujours la bonne réponse. Je trouve que lorsque vous restz fidèle aux intentions et que vous concevez à la fin, vous en sortez.

Les schémas sont conçus pour l'isolation de l'espace de noms. Par exemple, lors de la design d'un système SaaS, les schémas peuvent être utilisés très efficacement pour séparer les préoccupations des locataires multiples. Les schémas peuvent également être utilisés pour séparer le test de la production ou datatables d'une application d'une autre. Et ce n'est pas seulement pour les tables mais pour les procédures stockées et tous les autres objects de la database.

DB2 fournit un registre spécial appelé CURRENT SCHEMA qui vous permet de coder les noms d'objects non qualifiés mais de passer au bon schéma en définissant simplement le registre spécial CURRENT SCHEMA comme suit:

 SET CURRENT SCHEMA = 'Production' 

Ceci, à mon avis, est une bien meilleure approche que l'utilisation de synonymes.