Discussion :

[SQLpro]

Non, je dirais celui qui a du temps et de l'argent à dépenser en terme de réglage très fin pourra s'intéresser plus à Oracle, mais en sachant que c'est plutôt vers l'entretien d'une Rolls, que se situe le coût.
Pour d'autres, l'entretien simplifié d'une VW suffit... Mais n'oublions pas que VW à racheter Bentley et Rolls Royce !!! ;-)
Bref en matière d'ultra luxe il n'existe guère plus que la Maybach que j'ai eu l'honneur de piloter (Exelero) en essais au circuit du Luc en Provence... et ça c'est de la bagnole... Parole de motard !!!

A +

[Waldar]

Un bout d'un post que j'ai mis dans le forum Oracle après l'intervention de SQL Pro, mais il a plus sa place ici.

************************************************

De mon côté j'ai une plus longue expérience SQL avec Oracle qu'avec SQL Server.
Je travaille dans la BI donc quand j'interviens les applications sont déjà terminées.

Ce que je trouve déroutant avec SQL Server ce sont les paramètres par défaut suivants :
- commit implicite si on ne déclare pas de transaction
- pas de format de date explicite (convert avec des type 101 102 et cetera, ou cast depuis les paramètre locaux ou format ISO si j'ai bien suivi)
- typage de donnée conservé sans regarder l'opérateur : 5/2 = 2
- collation CI plus ou moins par défaut : 'Aeé' = 'aEÉ'
- rtrim plus ou moins par défaut également : 'A' = 'A '

S'ajoute à celà un peu de retard en SQL sur Oracle :
- les analytiques de SQL:2008
- expressions régulières en SQL natif
- les jointures externes partitionnées
- la clause model non normative

Si je dis des inepties n'hésitez pas à me reprendre ça améliorera mon quotidien !

[SQLpro]

- commit implicite si on ne déclare pas de transaction

Vous pouvez changer cela avec SET IMPLICIT_TRANSACTIONS

- pas de format de date explicite (convert avec des type 101 102 et cetera, ou cast depuis les paramètre locaux ou format ISO si j'ai bien suivi)

Le "format" de date cela n'existe pas. Une date est un type date. Ce n'est que dans l'IHM client qu'est fait la travail; sauf xi vous voulez explicitement dans une requête convertir la date en chaine. Dans ce cas il faut utiliser CAST (conversion US par défaut) ou CONVERT avec paramètre si vous voulez un format précis.
Voir l'article que nous avons écrit à ce sujet : http://baptiste-wicht.developpez.com...-sql/datetime/

- typage de donnée conservé sans regarder l'opérateur : 5/2 = 2

C'est la norme SQL qui l'impose : si les opérations sont faites sur des entiers, alors le résultat est un entier. Le typage du résultat est "au pus juste"

- collation CI plus ou moins par défaut : 'Aeé' = 'aEÉ'

C'est un paramètre du SQL normatif, définissable :
1) d'installation du serveur (la plupart des développeurs passent à côté lors de l'install)
2) de la base
3) de chaque colonne crée dans la table ou la vue
4) de toute expression faisant des opérations sur littéraux
Que voulez-vous de mieux ?
De plus il y a plus de 2000 collations disponibles en 2008 :
SELECT *
FROM ::fn_helpcollations()
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...er/collations/
Notons qu'Oracle ne sait toujours pas travailler les collation et en est resté avec cette chose immonde qu'est le NLS

- rtrim plus ou moins par défaut également : 'A' = 'A '

C'est la norme SQL qui l'impose.
Cependant vous pouvez paramétrer cela pour faire tout un tas de choses hors normes : SET ANSI_DEFAULTS et en particulier SET ANSI_PADDING

- les analytiques de SQL:2008

Il y manque effectivement la clause de fenêtrage (ROWS RANGE) mais tout ceci n'a été finalisé dans la norme que dans la version 2008. Voir l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/SQL2008/

- expressions régulières en SQL natif

Vous avez raison, mais la norme SQL c'est l'opérateur SIMILAR TO. Est-il implémenté en Oracle ? En tous cas je ne l'ais pas vu...
Donc SQL Server et Oracle en sont au même point : appel d'une fonction externe.

- les jointures externes partitionnées
- la clause model non normative

J'avoue mon ignorance... Quelle sont ces exotiques choses ? En tout cas n'existe pas dans la norme SQL...

Bref, je comprend que vous ne savez pas de quoi vous parlez, ce qui ne vous empêche pas de critiquer !

A +

[Waldar]

Mais non voyons, je ne critique pas je partage les différences qui méritent mon attention selon que je sois sous Oracle ou SQL Server lorsque j'écris des requêtes.

Je ne suis pas dans une vendeta versus tel ou un tel éditeur, j'ai pris le soin de préciser le contexte de mon intervention :
"De mon côté j'ai une plus longue expérience SQL avec Oracle qu'avec SQL Server. Ce que je trouve déroutant avec SQL Server ce sont les paramètres par défaut suivants".

Je n'ai ni dit mauvais, ni insurmontable, j'ai bien écrit déroutant - découlant de mon expérience plus importante avec Oracle.

Vous avez raison celà dit, je n'ai pas toute la norme en tête. Je l'ai surtout apprise sur ce forum et notamment grâce à vos papiers et vos interventions très (très très) rigides sur ce point.

J'ignorais effectivement que certains de ces paramétrages par défaut étaient stipulés dans la norme SQL (le trim, et la consistance des typages).
Je reste sur mon impression d'étrangeté.

Pour le format de date je parlais bien de spécifier le format de l'affichage. Je suis spécifiquement intransigeant sur ce point. Si un fournisseur m'envoie un fichier à intégrer dans le SI, avec des dates par exemple "AAAAMM/JJ", je dois aller regarder dans les tables de convert pour trouver ce qui convient le mieux.
Chez Oracle c'est plus simple avec to_date(<champ>, 'yyyymm/dd').

Pour les expressions régulières la syntaxe Oracle ne suit pas la norme, mais les fonctions sont bien built-in (après je ne sais pas où elles sont exécutées).
La requête suivante fonctionne depuis 10g :

Code :

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

1
2
select * from <matable>
where regexp_like(<col1>, '^[[:digit:]]{4}')

Côté analytiques je pensais surtout aux fonctions en elles-même qui existe chez Oracle et pas encore chez Microsoft pour des raisons de normalisations :
"ntile", "lead", "lag", "first_value", "last_value"

Encore une fois je ne sais pas ce que la norme impose donc c'est peut-être une erreur de ma part, mais du côté de fonctions plus anciennes comme "sum", "min", "max", "avg" ne permettent pas d'insérer de tri dans la fonction de fenêtrage et donc pas de somme cumulative, par exemple :

Code :

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

1
2
with test(nb) as (select 0 union all select 1 union all select 2)
select nb, SUM(nb) over(order by nb) from test

Fonctionne bien chez Oracle aux "from dual" et à la syntaxe de la CTE près.
Tout ceci reste contournable mais ça simplifie l'écriture de requêtes complexes.

Merci pour les informations sur les collations, c'est un domaine dans lequel je n'ai que peu d'expérience.

Pour les deux dernières ce n'est pas dans la norme.
Les partitioned outer joins pourrait bien y finir car c'est relativement simple et utile en reporting. J'ai récemment posté un exemple ici.
La clause model c'est moins digeste. Ca permet de créer/modifier des lignes en spécifiant des règles. Antoun a traduit un tutorial ici (d'ailleurs il manque la troisième partie ).

Pour finir une syntaxe qu'Oracle a récupéré chez SQL Server : PIVOT / UNPIVOT, qui ne sont pas dans la norme non plus (j'ai lu ça dans un de vos posts, et je vois d'ici vos cheveux se hérisser sur votre tête car vous n'aimez pas)

[orafrance]

Il est vrai que si suivre la norme est important, j'ai du mal à voir du mal quand un éditeur ajoute des fonctionnalités supplémentaires comme la jointure externe partitionnée (langue de molière oblige ) qui a un réel intérêt pour le reporting et allège énormément la syntaxe.

Après, on peut pas en vouloir au concurrent de s'être fait "griller" sur certaines notions, faut bien que chacun se différencie et maintenant c'est plus trop sur les qualités techniques qu'Oracle ou MS arriveront à faire la différence tant il me semble évident qu'ils se valent du strict point de vue "core" (gestion des perfs, réplication, haute dispo,...).

[SQLpro]

Je l'ai surtout apprise sur ce forum et notamment grâce à vos papiers et vos interventions très (très très) rigides sur ce point.

Certes je suis rigide, mais il y a une raison essentielle. La plupart des internautes et développeurs pensent avoir appris SQL, alors qu'ils ont appris du MySQL, du Oracle ou du Transact et l'on voir les dégâts que cela cause à tous les niveaux... C'est pourquoi j'ai pris partit de défendre SQL (le langage et donc la norme), car avant tout la norme est faites par les professionnels et se trouve en moyenne plus intelligente que n'importe quel éditeur pris séparément. D'ailleurs le rapporteur de la norme SQL, n'est-il pas Jim Melton, principal conseillé technique pour Oracle ?

Pour le format de date je parlais bien de spécifier le format de l'affichage.

Pour l'affichage ce n'est pas du ressort d'un SGBDR, mais d'un outil client.

Si un fournisseur m'envoie un fichier à intégrer dans le SI, avec des dates par exemple "AAAAMM/JJ", je dois aller regarder dans les tables de convert pour trouver ce qui convient le mieux.
Chez Oracle c'est plus simple avec to_date(<champ>, 'yyyymm/dd').

La récupération de données est du domaine des outil d'ETL et non du SGBDR. Mais sachez cependant que c'est encore plus simple encore sous MS SQL Server, car vous n'avez pas de requête a récrire pour charger les données en fonction du format, ceci étant un paramètre de la session client :
SET FORMAT XXX;
avec XXX pouvant valoir : YMD, YDM, MDY, MYD, DMY, DYM.
Modifiable à tout moment.

Pour les expressions régulières la syntaxe Oracle ne suit pas la norme, mais les fonctions sont bien built-in (après je ne sais pas où elles sont exécutées).

Built-in ou pas ne change rien en terme de fonctionalité. Vous retrouvez la même sous SQL Server via CLR par exemple avec RegexMatches. http://msdn.microsoft.com/fr-fr/magazine/cc163473.aspx

Côté analytiques je pensais surtout aux fonctions en elles-même qui existe chez Oracle et pas encore chez Microsoft pour des raisons de normalisations : "ntile", "lead", "lag", "first_value", "last_value"

ntile existe sous MS, mais les autres sont trop récentes (norme SQL:2008) pour y avoir été déjà implantées.

du côté de fonctions plus anciennes comme "sum", "min", "max", "avg" ne permettent pas d'insérer de tri dans la fonction de fenêtrage et donc pas de somme cumulative,

Ce qui fonctionne aussi chez SQL Server, mais sans la fenêtre RANGE/ROWS. Effectivement c'est une différence que de ne pas pouvoir faire une somme cumulative, mais cela s'écrit très facilement via une CTE qu'Oracle a eu beaucoup de mal à introduire.

...les partitioned outer joins ... la clause model ...

Tout cela est du domaine de l'analytique et s'éloigne fortement du simple transactionnel. Dans ce cas plutôt que de complexifier le SQL de base fait pour des bases OLTP, il suffit d'utiliser un langage qui est un standard de fait comme MDX (Multi Dimensionnal Expression) qui est fait pour cela. Notons qu'a part Oracle qui joue cavalier seul sur ce sujet, presque tous les grand du décisionnel ont adhéré à MDX : SAS, SAP, Proclarity, Cognos, Business Objects...

Pour finir une syntaxe qu'Oracle a récupéré chez SQL Server : PIVOT / UNPIVOT, qui ne sont pas dans la norme non plus (j'ai lu ça dans un de vos posts, et je vois d'ici vos cheveux se hérisser sur votre tête car vous n'aimez pas)

Je n'aime pas car c'est une clause cosmétique. Elle n'apporte rien du tout si ce n'est de repositionner les données. Aucune valeur ajoutée, juste de la peinture...

A +

[voran]

Notons qu'Oracle ne sait toujours pas travailler les collation et en est resté avec cette chose immonde qu'est le NLS

Une (même petite) explication s'impose.
Sinon les posts sur developpez font finir en :

- studio management c'est horrible
- l'optimiseur de requête de SQL Server est tout pourri
- Oracle est pas gentil
...

Bref que du bonheur

[SQLpro]

Oracle est pas gentil

Enfin, une vérité vraie !!!

A +

[voran]

Enfin, une vérité vraie !!!

A +

C'est bien ce que je pensais

Et à part ça, vous reprochez quoi à NLS ?

[SQLpro]

Et à part ça, vous reprochez quoi à NLS ?

Ne répond pas à la problématique puisqu'est statique : impossible de faire un tri ou une jointure en changeant dynamiquement la collation.

Avec le NLS pouvez vous faire un :

Code :

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

...ORDER BY COL1 NLS Chinese

?

Avec le NLS pouvez vous faire des comparaisons en cahngeant la colation à la volée ?

Code :

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

...INNER JOIN T1.COL1 = T2.COL1 NLS Hebrew

?

C'est une des raisons qui a fait changer certains client d'Oracle à SQL Server car il était impossible de réaliser certains sites web mondiaux nécessitant une telle dynamicité. Un chinois devant pouvoir visualiser et trier ses données en fonction de sa culture de langue et un russe ou un juif (hébreu) de même, alors que les données sont dans la même table...

Lisez l'article que j'ai écrit sur les collations : http://sqlpro.developpez.com/cours/s...er/collations/

A +

[Waldar]

La réponse aux deux questions est oui, la syntaxe est par contre un peu plus encombrante mais reste compréhensible :

Code :

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

1
2
3
ORDER BY COL1 NLS Chinese
=>
ORDER BY NLSSORT(COL1, 'nls_sort=Chinese')

Code :

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

1
2
3
INNER JOIN T1.COL1 = T2.COL1 NLS Hebrew
=>
INNER JOIN NLSSORT(T1.COL1, 'nls_sort=Hebrew') = NLSSORT(T2.COL1, 'nls_sort=Hebrew')

Le chapître de la doc Oracle consacré à ce sujet : http://download.oracle.com/docs/cd/B...t.htm#NLSPG005

[orafrance]

Et en général c'est l'application qui fait un alter session en fonction du contexte pour éviter d'allourdir les requêtes. Le site web d'Oracle est un parfait exemple pour montrer que l'internationalisation est possible.

Les clients dont tu parles sont entourés d'incompétents c'est tout

[B.AF]

Et en général c'est l'application qui fait un alter session en fonction du contexte pour éviter d'allourdir les requêtes. Le site web d'Oracle est un parfait exemple pour montrer que l'internationalisation est possible.

Les clients dont tu parles sont entourés d'incompétents c'est tout

+1. Et dans la majorité des applications qui ont ce genre de besoins, il n'est pas évident qu'il faille le déléguer à la base.

Pareil pour la gestion des dates.

Tout ce qui est écrit relève d'un principe qui est de dire que tous les traitements sont délégués au SGBD.

Ok, mais ce n'est pas nécessairement le cas, j'ai un faible aujourd'hui pour SQL server parce que dans ma structure le TCO est meilleur et globalement nous avons un outil assez transparent et qui monte bien en charge, maintenant, la grande différence entre les deux est qu'ils sont tous les deux un bon choix; la différence réelle est le TCO en focntion de la strucutre et du contexte.

Ce sont deux bons produits, concurrents, mais on davantage à se dire "je préfére" que c'est mieux --> Ca reléve du parti pris et de l'expérience.

C'est très compliqué aujourd'hui de trouver une personne connaissant suffisamment les deux pour trancher le débat. Par ex.; les collations.

[Jean-Philippe André]

Hello,

je profite de passer pa là pour indiquer en lien un comparatif (en anglais) des deux systèmes sur les aspects techniques et coûts en entreprises:
http://www.alinean.com/PDFs/Microsof...Study_2010.pdf
Ca date de 2010

[el_muchacho]

Au passage, la base de données analytique qui écrase les autres en terme de rapport performance/prix est l'allemand EXASol. Non seulement elle renvoie tout le monde dans les 22 mètres dans toutes les catégories où elle participe, mais à 3To et 10To, c'est sans appel. C'est une base distribuée in memory dont les principes semblent assez sains (du peu qu'on puisse en juger): orientée colonne, shared nothing, ACID, SQL. Le meilleur des deux mondes entre les bases distribuées comme Cassandra et les RDBMS. Le problème, c'est qu'en dehors du territoire allemand, EXAsol est pratiquement inconnu. Parmi les clients, DELL cite Sony et Olympus.
Wikipedia indique: "The license model is based on the allocated RAM for the database software (per GB RAM) and independent to the physical hardware. Customers gain the maximal performance if their compressed active data fits into that licenced RAM, but it can also be much larger."

Greenplum est comparable à la fois en technologie et p-ê en performances.
http://www.d1-solutions.com/fileadmi...e_database.pdf

Il reste que les infos sont floues, en particulier, elles prétendent être ACID. N'est-ce pas incompatible avec le fameux théorème PAC ? Qu'advient-il aux perfs si les données ne tiennent pas en RAM ?