Discussion :

[ypelissier]

Bonjour,
J'ai une table de 43 champs dont l'un d'eux met en place un niveau hiérarchique.

Est-il mieux de faire une vue hiérarchique de base avec la requête suivante :

Code :

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

1
2
3
4
5
6
7
8
9
WITH RecursiveQuery AS (
	SELECT	MonID, MonIDHierarchique, 0 Version
	  FROM	MaTableHierarchique
	UNION ALL
	SELECT	MTH.MonID, MTH.MonIDHerarchique, RQ.Version + 1
	  FROM	MaTableHirarchique MTH
			INNER JOIN RecursiveQuery RQ ON RQ.MonID = MTH.MonIDHerarchique)
SELECT	MonID, MonIDHerarchique, Version
  FROM	RecursiveQuery

Suivi d'une autre requête/vue pour avoir les autres infos :

Code :

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

1
2
3
SELECT	MonID, MonIDHerarchique, Version, Champ1, Champ2, ...
  FROM	MaVueHierarchique MVH
		INNER JOIN MaTableHierarchique MTH ON MVH.MonID = MTH.MonID

Ou bien tout mettre directement dans la vue hiérarchique comme ci-dessous

Code :

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

1
2
3
4
5
6
7
8
9
WITH RecursiveQuery AS (
	SELECT	MonID, MonIDHierarchique, 0 Version, Champ1, Champ2, ...
	  FROM	MaTableHierarchique
	UNION ALL
	SELECT	MTH.MonID, MTH.MonIDHerarchique, RQ.Version + 1, MTH.Champ1, MTH.Champ2, ...
	  FROM	MaTableHirarchique MTH
			INNER JOIN RecursiveQuery RQ ON RQ.MonID = MTH.MonIDHerarchique)
SELECT	MonID, MonIDHerarchique, Version, Champ1, Champ2, ...
  FROM	RecursiveQuery

La première organisation me parait plus légère à écrire mais plus lourde en ressources car ça demande de refaire un lien.
La seconde organisation me parait un peu plus lourde à écrire mais plus rapide car un lien de moins que la première. Par contre toutes les données sont trimballées et ça c'est peut-être plus lourd.

Et justement je ne sais pas laquelle de ces 2 organisations est meilleure à utiliser...

Si vous avez des infos sur les avantages ou inconvénient de l'une ou de l'autre de ces organisations, je suis preneur pour argumenter et arbitrer mon choix...

Merci

[aieeeuuuuu]

Bonjour,

La première organisation me parait plus légère à écrire mais plus lourde en ressources car ça demande de refaire un lien.

En effet, cette solution suppose une jointure supplémentaire, avec un plan d'éxécution moins efficace que la deuxième.

La seconde organisation me parait un peu plus lourde à écrire mais plus rapide car un lien de moins que la première. Par contre toutes les données sont trimballées et ça c'est peut-être plus lourd.

Non, il faut par contre éviter les select * sur la vue si vous n'avez pas besoin de toutes les colonnes.

J'opterai donc plutôt pour la deuxième solution :
Autant SQL n'est pas capable d'éviter la jointure (en fait inutile) de la première solution, autant il est capable de ne pas récupérer le contenu des colonnes présentes dans une vue mais non référencées par une requete sur la vue.

[ypelissier]

Non, il faut par contre éviter les select * sur la vue si vous n'avez pas besoin de toutes les colonnes.

Oui j'ai toujours entendu dire qu'il fallait éviter cette construction plus gourmande en ressources car le SGBDR doit en plus aller chercher les champs à prendre. Seul cas, select count(*) et je crois aussi dans un IF EXISTS(SELECT * ...)

[al1_24]

Seul cas, select count(*) et je crois aussi dans un IF EXISTS(SELECT * ...)

Dans ces deux cas, l'étoile n'a aucune signification.
D'ailleurs, dans le second cas, on écrit souvent IF EXISTS(SELECT 1 FROM ...) ou IF EXISTS(SELECT NULL FROM ...) pour bien appuyer le fait que les colonnes retournées par SELECT n'ont aucun intérêt.

[escartefigue]

Dans ces deux cas, l'étoile n'a aucune signification.
D'ailleurs, dans le second cas, on écrit souvent IF EXISTS(SELECT 1 FROM ...) ou IF EXISTS(SELECT NULL FROM ...) pour bien appuyer le fait que les colonnes retournées par SELECT n'ont aucun intérêt.

Je me permets de corriger, dans le cas d'un test d'existence, même avec un select * (if exists (select * from ....)), la requête ne transporte aucune donnée.
Il n'y a donc pas de colonne "retournée" mais seulement un booléen vrai/faux suite à une requete de ce type

Cela dit, je suis moi même adepte de la syntaxe if exists(select 1 from...)) qui a le mérite de lever toute ambiguïté

[al1_24]

J'aurais en effet du placer le termes "retournées" entre guillemets ou en italiques pour bien marquer que c'était une clause de style.

Je me souviens avoir rencontré, dans un passé ancien (suffisament pour que je ne me souvienne plus de quel produit il s'agissait), un SGBD qui réclamait que les colonnes et expressions utilsées dans la clause WHERE ou HAVING d'une sous-requête EXISTS soient déclarées dans la clause SELECT de celle-ci.