Utilisation du Row Value Constructor

Version imprimable

04/07/2007, 22h19
Antoun

Utilisation du Row Value Constructor
Bonjour à tous !

A chaque fois que j'essaie d'utiliser un Row Value Constructor sous Oracle, je me fais jeter lamentablement sous divers prétextes foireux, du genre "ORA-00920: invalid relational operator" ou "ORA-01796: this operator cannot be used with lists".

Cette fois-ci, j'ai besoin d'en avoir vraiment le coeur net. J'ai donc torturé la doc Oracle jusqu'à ce qu'elle me crache les infos suivantes (http://download.oracle.com/docs/cd/A...s3.htm#1034735) :

- la syntaxe pour comparer deux RVC serait la suivante :

Code:

(col1, col2) = ANY ((val1, val2))

effectivement, la requête suivante fonctionne sur apex.oracle.com :
Code:

1 2 3 select * from demo_customers where (cust_first_name, cust_last_name) = any (('Eugene', 'Bradley'))
- les seuls opérateurs autorisés seraient = et <> (ainsi que ses synonymes), ce qui limite largement l'intérêt de la chose...

A l'inverse, MySQL et SQL Server offrent une implémentation plus simple (pas besoin de ANY ni des doubles parenthèses) et surtout plus riche (possibilité d'utiliser <, <=, etc.) du RVC. Je ne vous cache pas ma déception :(

Je ne suis franchement pas un spécialiste Oracle. Quelle est votre expérience ? Est-ce que j'ai bien compris ? ou alors j'ai raté qqch ?
05/07/2007, 00h05
Pomalaix

Citation:

Envoyé par Antoun

les seuls opérateurs autorisés seraient = et <> (ainsi que ses synonymes), ce qui limite largement l'intérêt de la chose...

Oui, c'est exact, même en 10gR2, le schéma syntaxique indique que les comparaisons multicolonnes ne fonctionnent qu'avec l'égalité ou la différence.

Quant au ANY et consorts, à titre personnel je ne les utilise jamais, un
IN (<liste>)
remplaçant fort bien, y compris lors de comparaisons multicolonnes, un
= ANY(<liste>)
31/07/2007, 15h28
Antoun

Merci de la réponse ! plus je creuse Oracle et plus je suis déçu :(
31/07/2007, 15h34
pifor

Citation:

Envoyé par Antoun

plus je creuse Oracle et plus je suis déçu :(

Pour moi ce serait plutôt l'inverse... Voir par exemple le blog suivant (en français) qui compare la concurrence d'accès MySQL avec InnoDB (racheté par Oracle) et celle d'Oracle:
http://arkzoyd.blogspot.com/2007/07/...-pour-dba.html
31/07/2007, 15h40
Antoun

Normal, on ne recherche pas les mêmes choses. Si tu parles solidité et performance, c'est clair qu'Oracle est meilleur. Par contre, en termes de richesse et de normalisation du SQL...
31/07/2007, 15h56
Garuda

Citation:

Envoyé par Antoun

Normal, on ne recherche pas les mêmes choses. Si tu parles solidité et performance, c'est clair qu'Oracle est meilleur. Par contre, en termes de richesse et de normalisation du SQL...

+1 ;)
31/07/2007, 16h11
pifor

Citation:

Envoyé par Antoun

Normal, on ne recherche pas les mêmes choses. Si tu parles solidité et performance, c'est clair qu'Oracle est meilleur. Par contre, en termes de richesse et de normalisation du SQL...

En ce qui concerne la normalisation du SQL et du langage de procédure stockée, je suis plutôt d'accord: MySQL est plus respectueux des standards SQL et langage de procédure stockée qu'Oracle. Mais pour la richesse du SQL et du langage de procédure stockée, je ne suis pas vraiment convaincu.
31/07/2007, 16h20
Antoun

Je suis d'accord, le SQL procédural le + riche est sans conteste le PL/SQL. En même temps, cela me semble assez révélateur de la faiblesse du SQL statique d'Oracle. J'ai relativement peu d'expérience Oracle, et pourtant cela m'est déjà arrivé de devoir faire à travers du PL des trucs que j'aurais fait bcp + simplement avec MySQL ou SQL Server.