Discussion :

[Antoun]

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 :

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

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

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

Code :

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

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 ?

[Pomalaix]

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>)

[Antoun]

Merci de la réponse ! plus je creuse Oracle et plus je suis déçu

[pifor]

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

[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...

[Garuda]

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

[pifor]

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.

[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.