Jointure sur SUBSTRING?

Version imprimable

Bonjour,

Je me pose une question: est-il correct de réaliser un SUBSTRING dans un INNER JOIN?

En fait voici ma requête:

Code:

1
2
3
4
5
SELECT     dbo.X1.X1_1, BASE2.dbo.X2.X2_1, SUBSTRING(BASE2.dbo.X2.X2_1, 4, 8) AS teste, BASE2.dbo.X2.X2_2, 
                      BASE3.dbo.X3.X3_1
FROM         dbo.X1 INNER JOIN
                      BASE2.dbo.X2 ON dbo.X1.X1_1 = teste INNER JOIN
                      BASE3.dbo.X3 ON BASE2.dbo.X2.X2_2 = BASE3.dbo.X3.X3_1

Celle ci ne passe pas, mais celle là oui:

Code:

1
2
3
4
SELECT     dbo.X1.X1_1, BASE2.dbo.X2.X2_1, BASE2.dbo.X2.X2_2, BASE3.dbo.X3.X3_1
FROM         dbo.X1 INNER JOIN
                      BASE2.dbo.X2 ON dbo.X1.X1_1 = SUBSTRING(BASE2.dbo.X2.X2_1, 4, 8) INNER JOIN
                      BASE3.dbo.X3 ON BASE2.dbo.X2.X2_2 = BASE3.dbo.X3.X3_1

Donc ma question est simplement de savoir si cela est correct ou s'il vaut mieux que je le fasse dans le code de mon appli plutôt qu'en SQL.

Par avance merci ;)

07/07/2011, 09h59
Waldar

Syntaxiquement, votre seconde requête est en effet correcte.
La première ne fonctionne pas car les alias de colonnes du select sont évalués bien après que les jointures aient été exécutées.

Maintenant si vous êtes amené à faire ce genre de jointure, c'est qu'il y a un problème de conception du modèle de données.
07/07/2011, 10h27
papouuu

Merci bien,

En effet il y a de gros problèmes de conception sur les bases sur lesquelles je travaille mais je n'ai pas la main dessus :( Je suis donc obligé de procéder de cette manière:aie:
07/07/2011, 11h37
aieeeuuuuu

Bonjour,

ne pouvez vous effectuer aucune modification ? Ne pouvez vous pas au moins créer une vue indexée, reprenant le substring ?

Cela pourrait surement (à moindre frais) améliorer les perfs sans impacter les différentes applications déjà en fonctionnement.
07/07/2011, 14h32
SQLpro
Une solution efficace, serait de créer une colonne calculée persistante et de l'indexer; comme ceci :
Code:

1 2 3 4 5 6 7 8 9 10 USE BASE2; GO ALTER TABLE dbo.X2 ADD C_CALC_X2_1_4_8 AS SUBSTRING(X2_1, 4, 8) PERSISTED; GO CREATE INDEX X_25475431541354 ON dbo.X2 (C_CALC_X2_1_4_8); GO
Vous verrez aisément la différence en terme de perf !!!

Citation:

En effet il y a de gros problèmes de conception sur les bases sur lesquelles je travaille mais je n'ai pas la main dessus...

Ce ne sont donc pas vos données ????
Car si ce sont vos données, vous avez le droit de faire tout ce que Codd, l'inventeur des bases de données relationnelles indique dans le cadre de sa règle n°9.
Autrement dit vous avez le droit de rajouter des colonnes à des tables, des tables ou vues à la base, des procédures et des fonctions, sans que quiconque, y compris l'éditeur de l'application puisse y redire.
Il y a malheureusement des éditeurs malhonnêtes (et couvent incompétents) qui prétendent interdire par contrat que la base de données de l'utilisateur puisse être modifié sans perde la garantie ! Cette position est stupide en plus d'être contraire au droit comme à la jurisprudence.... En effet, si vos données vous appartiennent vous avez le droit de modifier la structure de la base, pourvue, comme le dit très bien Codd (et depuis 25 ans...) que les
changements de tous ordres, préservent les informations et ne leur portent théoriquement aucune atteinte
Imaginez combien il serait stupide que vous ne puissiez pas poser le moindre index !!!

A lire et en particulier les explications :
http://sqlpro.developpez.com/SGBDR/R...egles_codd.pdf

A +

Pour employer le même résultat d'une formule à plusieurs endroits (dans votre cas : en tant que colonne récupérée et que participant à la jointure), employez CROSS APPLY.

Code:

1
2
3
4
5
6
7
8
9
10
11
 
SELECT     dbo.X1.X1_1, BASE2.dbo.X2.X2_1, teste, BASE2.dbo.X2.X2_2, 
                      BASE3.dbo.X3.X3_1
FROM         BASE2.dbo.X2
 
CROSS APPLY (
SELECT SUBSTRING(BASE2.dbo.X2.X2_1, 4, 8) AS teste
) AS Formule
 
INNER JOIN  dbo.X1 ON dbo.X1.X1_1 = teste INNER JOIN
                      BASE3.dbo.X3 ON BASE2.dbo.X2.X2_2 = BASE3.dbo.X3.X3_1

07/07/2011, 15h45
aieeeuuuuu
Citation:

Envoyé par SQLpro

Il y a malheureusement des éditeurs malhonnêtes (et couvent incompétents)

avec du code comme ça :
Code:

1 2 3 4 INSERT INTO UneTableDontJaiLaFlemmeDeSpecifierLesColonnes SELECT * FROM UneAutreTableDontJaiLaFlemmeAussiDeSpecifierLesColonnes
Les effet de bords risquent d’être douloureux, même avec le simple ajout d'une colonne calculée... C'est pourquoi je proposais la création d'une vue indexée, qui ne devrait pas perturber les applications, et ne devrait même pas nécessiter la modification de la requête écrite par papouuu.
07/07/2011, 16h13
SQLpro

Tu as raison pour le SELECT *, mais cela ne devrait jamais être utilisé en prod.
Moralité, faire un coup de profiler pour voir si cela est, et corriger, ou demander la correction à l'éditeur.

Parce que le coup de la vue indexée, lorsqu'il n'y a pas d'agrégats, c'est quand même du volume conséquent en sus, donc de la place mémoire bouffée, donc des perfs en moins....

A +
07/07/2011, 16h35
papouuu

Merci à tous pour vos réponse toutes très instructives, j'ai eu pas mal de maintenance d'applis aujourd'hui donc j'ai pas encore avancé, cela va me permettre d'étudier les meilleurs solutions, en effet la vue peut être une bonne idée..

Sinon pour répondre à vos questions, surtout de hurlez pas ^^

Je n'ai pas la main sur les bases comme dis précédemment, je travaille dans une banque en fait et donc je suppose que c'est normal de ne pas avoir accès à tout ceci.

Pour faire mes applis, je dois créer un script de récupération des données pour les insérer dans une base que je crée sous mysql. Et c'est sur ces bases mysql que se réalisent les différents traitements des applications.

C'est très moche je sais mais je suis qu'un petit développeur étudiant en boulot d'été donc je fais avec ce que l'on me donne. ^^
07/07/2011, 18h24
aieeeuuuuu

Citation:

Envoyé par SQLpro

Tu as raison pour le SELECT *, mais cela ne devrait jamais être utilisé en prod.

tout à fait. cela ne devrait jamais...:calim2:

Citation:

Parce que le coup de la vue indexée, lorsqu'il n'y a pas d'agrégats, c'est quand même du volume conséquent en sus, donc de la place mémoire bouffée, donc des perfs en moins....
A +

oui c'est vrai aussi, cela dit, on peut limiter la vue par exemple à la colonne substring et l'identifiant. Je vois cela comme une façon détournée de créer un index sans ajouter la fameuse colonne calculée.
Mais il est clair que sur une base dont on à la parfaite maitrise, la colonne calculée serait la meilleure solution...

surtout que la vue pourrait aussi avoir d'autres inconvénients. par exemple si un script de migration tente de supprimer (pour une raison ou pour une autre) la table en question, le script ne passera pas, la vue étant liée au schéma...
07/07/2011, 22h40
zinzineti

Citation:

Envoyé par SQLpro

Autrement dit vous avez le droit de rajouter des colonnes à des tables, des tables ou vues à la base, des procédures et des fonctions, sans que quiconque, y compris l'éditeur de l'application puisse y redire.
Il y a malheureusement des éditeurs malhonnêtes (et couvent incompétents) qui prétendent interdire par contrat que la base de données de l'utilisateur puisse être modifié sans perde la garantie ! Cette position est stupide en plus d'être contraire au droit comme à la jurisprudence.... En effet, si vos données vous appartiennent vous avez le droit de modifier la structure de la base, pourvue, comme le dit très bien Codd (et depuis 25 ans...) que les
changements de tous ordres, préservent les informations et ne leur portent théoriquement aucune atteinte
Imaginez combien il serait stupide que vous ne puissiez pas poser le moindre index !!!

A +

Personnellement, la tentation de tout "vérouiller" est grande ... Lorsqu'on je développe une appli et que je dois assurer la maintenance dernière. Généralement lorsque le client fait des bidouilles dans la base de données et que l'appli ne marche plus... on perd énormément du temps à identifier la cause du "ça ne marche plus !"
A la question aviez vous fait des modifications particulières sur l'appli ?
La réponse est généralement NON ! NON on n'a rien fait ! si cette situation arrive quelques semaines après livraison, on a encore en tête les logiques de l'appli... Mais si l'anomalie survient quelques mois après... on met souvent du temps pour régler le problème. D'où la tentation de "tout vérouiller" - "on ne touche à rien!"

Mais lorsque j'ai la responsabilité d'assurer le bon fonctionnement d'une appli que je n'ai pas développé et que je n'ai pas la main sur tout (bases de données, processus, services, ...) ça m'énerve ...
C'est souvent le cas des applis "TURNKEY" où on ne peut même pas accéder à la base de données pour faire un simple SELECT.
Très souvent l'éditeur de la solution "TURNKEY" ne fournit même pas la procédure de restauration en cas de crash des serveurs (appli + BD) ... la suite dans le prochain épisode ...
A+