Discussion :

[filobilo]

Bonjour,

Je bloque sur un pti pb.

Le contexte. J'ai créer une procédure qui fait quelques traitements...

Hors, en fonction de la valeur d'un champ, transmis en paramètre, je vais travailler sur des tables différentes, qui ont les mêmes colonnes. Ces tables contiennent des configurations liés au champ transmis en paramètre.

Donc au lieu de faire 4 tests à chaque instructions pour savoir sur quels tables travaillés, j'aurais voulu créer un alias sur ma table que je pourrai utiliser tout au long de ma procédure, et la détruire en fin de procédure.

Je suis au debut partie sur les vues, mais cela ne fonctionne pas dans une procédure stockée, et créer une vue pour recréer une table n'est pas très optimisé.

Après recherche, je pencherai sur l'utilisation de "Create Type" mais je n'arrive pas à en trouver la bonne syntaxe.

Je pensai aussi éventuellement créer une vue regroupant toutes mes tables en ajoutant mon fameux champ transmis, mais j'ai peur que cette vue deviennent trop lourd.

Auriez vous quelques pistes de recherche ?

Merci par avance.

[jero44]

bonjour,
Si j'ai bien saisie votre propos vous souhaitez construire dynamiquement la reqûete en fonction de la valeur de l'un des paramètres.
Pour la construction dynamique de requete il est nécessaire d'utiliser sp_executesql.

[SQLpro]

Auriez vous quelques pistes de recherche ?

Oui : pourquoi avez vous créé n tables ayant les mêmes colonnes ??? C'est une erreur dans le modèle. Il suffit de tout regrouper dans la même table ! En vertu d'une principe simple : même infos = même table.
Si vous voulez distinguer les lignes de votre table, rajoutez simplement une colonne.
Vos requêtes deviendront, simples, élégantes efficaces et rapide si vous mettez les index adéquat. De plus vous respecterez l'art de la modélisation de données et à terme irez 10 fois plus vite en développement !

A +

[elsuket]

Bonjour,

Il vous faudrait plutôt regrouper ces 4 tables en une seule, et il vous sera peut-être nécessaire ensuite d'ajouter une colonne à cette nouvelle table pour faire la distinction entre les 4 "sous-ensembles" donc vous disposez actuellement dans 4 tables.

Je pensai aussi éventuellement créer une vue regroupant toutes mes tables en ajoutant mon fameux champ transmis, mais j'ai peur que cette vue deviennent trop lourd.

Partant ce que je viens de vous proposer, il vous "suffit" d'indexer proprement la table unique en étudiant les requêtes qui la spécifient, notamment leur plan

@++

[elsuket]

ha ben on a posté en même temps, je n'ai donc fait que vous confirmer ce que vous propose SQLPro

@++

[SQLpro]

oui, mais moi j'ai gagné !!!! na

A +

[elsuket]

Il est fou SQLPro

@++

[filobilo]

Je m'attendais à la réponse, il faut créer une seul table, problème de conception.
Mais malheureusement cela n'est pas possible pour plusieurs raisons.... mais là n'est pas le débat.

je ne veux pas non plus construire ma requete dynamiquement.

Je pense que la solution serait de construire une vue dans laquelle je stockerai l'intégralité des colonnes identiques pour interroger cette vue avec mon fameux champ en paramètre dans la clause.

En gros ma demande était :
au lieu d'avoir la syntaxe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
select * from TABLE A where.....
 
declare A as ma table TABLE
>> select * from A

Merci toutefois d'avoir essayer de resoudre mon problème.
Je laisse le post ouvert, si un jour j'ai la solution je viendrai la poster.

[elsuket]

Mais malheureusement cela n'est pas possible pour plusieurs raisons

C'est au départ que la conception est mauvaise, et maintenant que la base de données à commencé à vivre, difficile de revenir en arrière ...

Vous pouvez créer une vue indexée, mais je ne sais pas sur quelle colonne de chaque table vous allez pouvoir poser l'index cluster, puisqu'il faut que les valeurs de clé soient évidemment uniques ...

declare A as ma table TABLE

Plus précisément cela donnerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DECLARE @A TABLE

Ne faites pas cela car aucune statistique n'est maintenue sur les variables de type table, donc il n'est alors pas possible à l'optimiseur de requêtes de calculer un bon plan de requête.
De plus ces "tables" sont stockées dans TempDB, base de données système à laquelle le moteur de base de données a largement recours.

Vous vous en sortirez mieux avec une vue indexée

@++

[filobilo]

l'exemple n'etait pas pour déclarer une table variable.

Juste pour expliquer que je voudrais créer un alias sur ma table, et que cette alias soit visible tout le long de la procédure, et non juste sur une requête.

[elsuket]

je ne veux pas non plus construire ma requete dynamiquement.

Qu'est-ce qui vous en empêche ?

Juste pour expliquer que je voudrais créer un alias sur ma table, et que cette alias soit visible tout le long de la procédure, et non juste sur une requête.

Cela n'est pas possible, les alias de tables participant à une jointure ne sont visibles que pour la requête en cours.
Je ne vous le conseille pas, mais vous pouvez créer des synonymes (CREATE SYNONYM), mais je commence à ne plus comprendre votre démarche ...

@++

[filobilo]

Merci, c'est exactement ce que je cherchais.

pour expliquer en gros ma demande :
j'ai plusieurs tables, différentes mais semblables sur quelques champs
PRODUIT_A, PRODUIT_B....


Je crée une procédure qui execute un travail sur ces tables.
une variable passé en paramètre me donne sur quel produit je travaille.
Cette procédure est multi produit, et au lieu d'interroger une variable pour savoir sur quelle table travailler, le synonym me permet de déclarer une fois pour toutes mes tables de travail.

ceci me permet de ne pas écrire x fois la même procédure pour des tables de noms différents, ou de tester ma variable à chaque requête de ma procédure.

Ceci combiné avec une vue me permet donc d'optimiser un max ma procédure, en nb de ligne de code, en performance, et en lecture.

Merci.

[elsuket]

Ceci combiné avec une vue me permet donc d'optimiser un max ma procédure, en nb de ligne de code, en performance, et en lecture.

A tester, car il faut quand même que le moteur résolve les synonymes ...
Je ne sais pas quel impact cela a sur les performances ...

@++