[OracleXE] Distinct et CLOB

Bonjour,
alors voilà j'ai une requête qui contient une colonne de type CLOB en retour mais j'aimerais faire un distinct sur les lignes retournées. Or le distinct et les type lob ne s'aiment pas...
Ma table

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE Personne( NumPersonne NUMBER(10) NOT NULL, Nom VARCHAR2(25), Prenom VARCHAR2(25), Observation CLOB, PRIMARY KEY (NumPersonne) );

---

Ma requete

Code:

---

1 2 3 4 5

SELECT DISTINCT P.NumPersonne, P.Nom, P.Prenom, P.Observation FROM Personne P INNER JOIN Voyages V ON V.NumPersonne = P.NumPersonne WHERE V.DateDebut > '01/01/2009'

---

Quelqu'un aurait une idée ?

Si ta colonne "Observation" ne dépasse pas les 4000 caractères, tu peux réécrire ta requête comme suit :

Code:

---

1 2 3 4

SELECT DISTINCT P.NumPersonne, P.Nom, P.Prenom, TO_CHAR(P.Observation) FROM Personne P INNER JOIN Voyages V ON V.NumPersonne = P.NumPersonne WHERE V.DateDebut > '01/01/2009'

---

Rachid

Citation:

---

Restrictions on DISTINCT and UNIQUE Queries
When you specify DISTINCT or UNIQUE, the total number of bytes in all select list expressions is limited to the size of a data block minus some overhead. This size is specified by the initialization parameter DB_BLOCK_SIZE.
You cannot specify DISTINCT if the select_list contains LOB columns.

---

Mais, faire "Select distinct colonne" clé primaire est erroné, n'est pas vrai ?

Citation:

---

Envoyé par mnitu

Mais, faire "Select distinct colonne" clé primaire est erroné, n'est pas vrai ?

---

Etant donné que je fais une jointure, cela peut remonter plusieurs fois la même ligne.

@mydb_server:
Merci pour ta réponse, le problème c'est que derrière j'utilise des composants qui attendent une colonne de type Mémo :

Code:

---

Personne: Type inadéquat pour le champ 'Observation', attendu : Memo actuel : String

---

Bon j'ai supprimé les DISTINCT dans les requêtes sur les tables qui avaient une colonne de type BLOB et ça ne gène pas mon programme...Mais bon...

Mon application étant multibase, elle fonctionnait trés bien sous SQL Server et MySQL. La norme est pourtant claire sur le distinct et les colonnes de type LOB. Cela voudrait dire que les autres SGBD ont optimisés leur parser SQL dans ce sens, permettant ce genre de requête....?!

Merci, en tout cas, à tous les deux d'avoir bien voulu répondre à ma demande ;)

Votre syntaxe n'est pas adpatée à ce que vous voulez faire.
En l'occurence, vous cherchez les personnes qui ont fait au moins un voyage depuis 2009.

Celà s'écrit ainsi :

Code:

---

1 2 3 4 5 6

SELECT P.NumPersonne, P.Nom, P.Prenom, P.Observation FROM Personne P WHERE EXISTS (SELECT NULL FROM Voyages V WHERE V.NumPersonne = P.NumPersonne AND V.DateDebut > to_date('01/01/2009', 'dd/mm/yyyy'))

---

Et là, plus de problème de distinct.

Citation:

---

Envoyé par Waldar

Votre syntaxe n'est pas adpatée à ce que vous voulez faire.
En l'occurence, vous cherchez les personnes qui ont fait au moins un voyage depuis 2009.

Celà s'écrit ainsi :

Code:

---

1 2 3 4 5 6

SELECT P.NumPersonne, P.Nom, P.Prenom, P.Observation FROM Personne P WHERE EXISTS (SELECT NULL FROM Voyages V WHERE V.NumPersonne = P.NumPersonne AND V.DateDebut > to_date('01/01/2009', 'dd/mm/yyyy'))

---

Et là, plus de problème de distinct.

---

D'accord, mais du coup je me pose la question qu'en est il niveau performance ?

C'est meilleur que la jointure :
- moins de données rappatriées
- pas de distinct
- la recherche d'existence s'arrête dès qu'un élément correspond

Ah...mais cela ré-exécute la requête sur la table voyage pour chaque ligne ?
De plus il me semblait qu'avec les jointures le SGBD optimisé un max en utilisant les index ?

C'est une forme de jointure, comparez les plans d'exécutions, vous verrez qu'ils sont relativement proches.

De même, si le nombre de personnes ayant effectué un voyage est relativement faible, vous pourriez aussi utiliser un IN :

Code:

---

1 2 3 4 5

SELECT NumPersonne, Nom, Prenom, Observation FROM Personne WHERE NumPersonne IN (SELECT NumPersonne FROM Voyages WHERE DateDebut > to_date('01/01/2009', 'dd/mm/yyyy'))

---

Le mieux reste bien entendu de tester tout cela, seul vous avez votre base de données entre les mains !