2012-05-17 1 views
2

Je dois vérifier si un utilisateur spécifique est déjà référencé dans l'une de nos tables de transactions (nous avons environ 10 tables de transactions). J'ai suggéré d'utiliser une vue qui contiendra tous les utilisateurs qui sont déjà référencés, puis l'équipe DEV pourrait juste sélectionner à travers cette table pour savoir si les données qu'ils recherchent sont là ou non,Utilisation de UNION select à l'intérieur d'une vue

alors voici ma requête pour l'affichage:

SELECT DISTINCT user_ID 
FROM transaction_table_1 

UNION 

SELECT DISTINCT user_ID 
FROM transaction_table_2 

UNION 

SELECT DISTINCT user_ID 
FROM transaction_table_3 

UNION 

SELECT DISTINCT user_ID 
FROM transaction_table_4 

[...] 

Pour l'instant cela fonctionne, mais ma question est, est-ce une bonne idée? L'exigence demande que je fournisse seulement un script (ou une vue) et pas une procédure stockée, je pense que ce serait mieux avec un SP puisque je pourrais juste faire une rapide instruction IF EXIST() pour chaque tableau et vérifier si l'utilisateur du paramètre existe dans n'importe laquelle de la table, mais ils voulaient vraiment que ce soit seulement un script qu'ils pourraient vérifier (et pas d'utilisation de variables). Pouvez-vous me donner des conseils sur une meilleure façon de faire cette exigence, qui aurait moins d'impact sur les performances puisque ce n'est peut-être pas la solution optimisée pour cette exigence.

TIA, Rommel

+0

IF EXISTS() est la solution la plus rapide. Que voulez-vous dire en n'utilisant pas de variables? Comment cela fonctionnerait-il sans variables et cette vue que vous avez maintenant? – Ovi

+0

Ils utilisent hibernate pour obtenir des données de la base de données et quand j'ai suggéré un script qui utilise des variables "Declare @status INT", ils ont dit que ça ne marcherait pas et il serait mieux si je peux fournir juste une requête, J'ai suggéré d'utiliser une vue. Le plan original je pense était d'utiliser IF EXISTS() mais ils ne voulaient pas plonger dans la base de données plus d'une fois juste pour vérifier si l'utilisateur qu'ils recherchent a déjà fait une transaction. – Rohml

Répondre

2

Eh bien, vous pouvez supprimer le DISTINCT parce UNION fait déjà :)

SELECT user_ID 
FROM transaction_table_1 

UNION 

SELECT user_ID 
FROM transaction_table_2 

UNION 

SELECT user_ID 
FROM transaction_table_3 

UNION 

SELECT user_ID 
FROM transaction_table_4 

Mais puisque vous devez utiliser une vue, je ne vois pas comment faire différemment.

+0

Salut, merci. Mais le syndicat serait-il toujours une bonne idée? Je pense qu'ils seraient d'accord s'il s'agissait d'un script SELECT, mais avec le nombre de tables requises, je ne suis pas sûr qu'une instruction SELECT serait bonne. Ce que j'ai peur, c'est que plus de transactions sont placées sur les tables de transaction que la performance va prendre un coup. – Rohml

+0

vous ne pouvez pas fuir une union, maintenant vous pouvez faire UNION comme je l'indique ou UNION ALL et distinct comme @ Paddy a déclaré. –

1

D'un point de vue de la performance, je structurer la requête légèrement différente:

SELECT DISTINCT user_ID 
FROM (

    SELECT user_ID 
    FROM transaction_table_1 

    UNION ALL 

    SELECT user_ID 
    FROM transaction_table_2 

    UNION ALL 

    SELECT user_ID 
    FROM transaction_table_3 

    ... 
) x 

Cela permettra de réduire le nombre de scans d'index uniques qui doivent être fait à 1 - plutôt que d'avoir un à chaque fois un UNION est exécuté

+1

Ouais les gens ont tendance à ne pas savoir/oublier que UNION rejette les dupes - UNION ALL comprend toutes les rangées alors que UNION fait un travail supplémentaire pour exclure les doublons – Charleh

+0

Merci Paddy, je vais regarder dans ce domaine. – Rohml