Discussion :

[flamant]

Bonjour,
Je développe une application en Java/J2ee avec JPA/HIBERNATE comme framework de persistence
j'ai les 3 tables suivantes

Code :

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

1
2
3
4
 
User
-userId
-.........

Code :

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

1
2
3
4
5
6
7
 
Gouts
-id
-userId
-prop1
-prop2
-Prop3

Code :

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

1
2
3
4
5
6
7
 
Category
-id
-userId
-prop4
-prop5
-Prop6

Pour les besoins d'une future requête, dès que j'ai déterminé un User (donc dès que userId est connu), j'aurais besoin de créer 2 vues, la vue VueGouts extraite de la table Gouts pour un userId déterminé

Code :

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

1
2
3
4
5
 
VueUserGouts
-prop1
-prop2
-Prop3

et la vue VueCategory extraite de la table Category pour un userId déterminé

Code :

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

1
2
3
4
5
 
VueUserCategory
-prop4
-prop5
-Prop6

Ma première question est : est-ce possible ? notamment avec Hibernate
Ma deuxième question est : est-ce que ça a un intérêt ? Mon idée est de créer ces vues dès que je connais le User (donc le userId) de manière à gagner en performance dans ma future requête (et d'éviter des jointure supplémentaire avec la table User) ?
Ma troisième question est : je pense qu'il faudrait une vue paramétrisée (le paramètre étant userId) ? est-ce possible avec SQL server et est ce possible de l'utiliser avec Hibernate (et si possible comment) ?

Si vous pouviez joindre des liens utiles, merci

[StringBuilder]

Le plus simple et le plus performant, c'est de ne pas utiliser NHibernate…

Sinon, oui, tu peux utiliser des vues : elles seront à priori vues comme une table.
Et une vue paramétrée n'existe pas.

Tu peux utiliser une procédure stockée qui exécute une requête paramétrée, ou une fonction de type table qui retourne le résultat d'une telle requête.
Ceci dit, une simple sélection dans la vue avec un filtre sur le userid sera aussi performante et plus simple à utiliser (si demain du veux filtrer sur autre-chose ça évite de tout réécrire)

[SQLpro]

Et une vue paramétrée n'existe pas.

Si tu as la possibilité de faire cela avec une fonction table online qui joue exactement ce rôle.

A +

[StringBuilder]

C'est effectivement ce que j'ai proposé, mais ce n'est pas à proprement parler une "vue paramétrée".

[flamant]

Merci pour ta réponse StringBuilder,

le problème est que je veux utiliser une vue qui doit être prête à l'emploi pour les besoins d'une future requête.

Et le contenu de cette vue dépend par exemple de la table

Code :

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

1
2
3
4
5
6
7
 
Gouts
-id
-userId
-prop1
-prop2
-Prop3

filtrée par userId

J'ai l'impression qu'une vue paramétrée ne ferait pas l'affaire car elle n'existe pas comme tu le dis. Peux tu me donner un exemple pour résoudre un tel problème ?

[Monstros Velu]

Bonjour,

Je pense qu'une simple procédure stockée répondra à ton besoin :
Elle prendra en paramètre le userId
Elle renverra le résultat de la requête

Code :

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

1
2
3
4
5
6
7
8
 
CREATE PROC GoutPourUtilisateur
@UserId int
AS
SELECT Id, UserId, prop1, prop2, prop3 
FROM Gouts
WHERE UserId = @UserId;
GO

En option, si tu as un index sur la table Gout, colonne UserId incluant les autres colonnes de résultat de la requête, la réponse devrait être rapide.

Si, pour une future requête, tu veux faire une vue : Sache que si ta requête fait une jointure sur la table goût, tu as toutes les chances que ce soit plus performant que de calculer le goût et de le ramener dans ton autre requête, car SQL Server est fait pour ça. Cependant, sans connaitre la future requête, on ne peut pas savoir...

[aieeeuuuuu]

Bonjour,

Il faudrait donner plus de détail sur ce que vous voulez faire, car il y a de multiples façons de faire.
Par ailleurs, je ne vois pas pourquoi les solutions proposées ne conviennent pas.

Pour ce qui est des "vues paramétrées"... une fonction table en ligne en est l'équivalent... mais avec les éléments que vous avez fournis, je ne vois pas non plus pourquoi cela est nécessaire : une simple vue, filtrée par la suite, fera parfaitement le boulot...

[flamant]

Bonjour Monstros velu et aieeeuuuuu et merci pour vos réponses.

Sache que si ta requête fait une jointure sur la table goût, tu as toutes les chances que ce soit plus performant que de calculer le goût et de le ramener dans ton autre requête

Si une jointure dans ma requête finale sur userId est plus performante que de passer par une vue intermédiaire effectivement mon idée n'a pas d'intérêt.
Je vais avancer sur cette requête et reviendrai vers vous plus tard

[flamant]

Bonjour à tous, et merci pour vos réponses. J'ai fait mon poc sans utiliser de vues paramétrées dans ma requête finales mais simplement en faisant les jointures nécessaires et j'obtiens de bon résultats.

comme l'a dit Monstros velu

Sache que si ta requête fait une jointure sur la table goût, tu as toutes les chances que ce soit plus performant que de calculer le goût et de le ramener dans ton autre requête

Merci à tous encore