Discussion :

[Jean.Cri1]

bonjour,

Quelqu'un peut il concisement exposer ce que (d'apres les soit disant expert sybase) ferait toute la particularité de Sybase, à savoir :
-son fonctionnement qui serait resolument ENSEMBLISTE ( j'ai rien compris)
-le SARG et modes direct/différé
-le 'magic number'

D'avance merci.

[mpeppler]

bonjour,

Quelqu'un peut il concisement exposer ce que (d'apres les soit disant expert sybase) ferait toute la particularité de Sybase, à savoir :
-son fonctionnement qui serait resolument ENSEMBLISTE ( j'ai rien compris)

Sybase ne connais pas le "rownum" d'Oracle (p.ex.) donc il n'y a pas de façon simple d'accèder à une ligne particulière sauf avec une condition WHERE appropriée. Les curseurs ne sont en général pas conseillés. Et probablement quelques autres examples...

-le SARG et modes direct/différé

Le SARG (search argument) ne me semble pas être particulier à Sybase...
Les modes updates directs permettent d'être plus rapide (moins d'IO), mais à nouveau je ne pense pas que ce soit nécéssairement une prérogative de Sybase.

-le 'magic number'

C'est 0.33 - c'était (avant la 11.9.2) la selectivité utilisée par l'optimiseur. Depuis cette selectivité est modifiable, et dépend des données.

Michael

[Jean.Cri1]

Thanks,
J'ouvre une file pour le SARG.

[Fabien Celaia]

Dès la v.15, il y a une équivalence du rownum d'Oracle
ASE est ensembliste au même titre que la plupart des SGBDR du marché.
L'abus de langague a souvent lieu en ce qui concerne les triggers : en effet, ceux-ci ne se déclenchent qu'après la modif et permettent de gérer les modification de manière ensembliste via les tables deleted et inserted, et non pas de faire du ligne à ligne.

Pour les SARGs, bien que le nom diffère, l'utilisation des diverses conditions et jointures par l'optimiseur répondent à certaines règles similaires, quelle que soit la base. On peut déplorer chez Sybase par exemple le fait que les indexes sur fonction n'existent pas, mais on peut se réjouir par contre que l'optimiseur, dans son calcul de poids pour le choix optimum du bon SARG, est en mesure de différencier les pages en caches des pages en disque et de leur attribuer un poid différent, contrairement à l'optimiseur d'Oracle par exemple.

Le magic number est un poids arbitraire (et souvent mauvais) que l'optimiseur donne pour une condition donnée lorsqu'une valeur meilleure n'est pas disponible via la table des statistiques ou qu'il n'est pas en mesure de déterminer la colonne au moment de la compilation (d'où éviter les derivative tables, les sql dynamiques, ...) pour la sélectivité d'un index. Il n'y a pas que 30%... il y a plusieurs poids selon le type de condition. En teme de statistique toujours, Sybase est à mon avis bien meilleur qu'Oracle, car ses statistiques sont généralement mises à jour au fil de l'eau.

A mon avis, Oracle est bien plus riche en terme de language et de fonctionnalité que Sybase, mais bien plus sujet à bugs. L'optimiseur de Sybase est, à mon avis, bien plus malin que celui d'Oracle.