Discussion :

[SQLpro]

fadace nous disait

Ce que Oracle(9i) fait, mais pas MS-SQL(2000)
- sécurité au niveau ligne
- JVM inclue dans le moteur (mais sans support JIT)
- support SQLJ, niveau 0 et 1
- gestion cluster (optionnel), haute disponibilité (homis WSB)
- édition des plan d'exécution
- parallélisme pour insert et update (optionel)
- backup et restore parallèles
- tables de résumé
- roles définis par l'utilisateur
- gouverneur de ressources
- attribution de priorités (optionel)

Avec SQL Server 2005 (et nous en sommes bientôt à 2008...)

- JVM inclue dans le moteur (mais sans support JIT)
- support SQLJ, niveau 0 et 1

JVM non mais CLR (.net) oui, avec un avantage certains pour SQL Server : le niveau de sécurité, car SQL CLR est sous le contrôle du moteur de la base de données ce qqui ne me semble pas être le cas de Java !

- gestion cluster (optionnel), haute disponibilité (hormis WSB)

Cluster possible depuis la v 7 avec Windows Cluster Système
haute dispo possible par différerents moyens donct mirroring de BD depuis v 2005.

- édition des plan d'exécution

Possible depuis 2005 en XML

- parallélisme pour insert et update (optionel)

je ne sais pas depuis combien de temps cela se pratique pour SQL Server...

- backup et restore parallèles

existe depuis au moins la version 2000

- tables de résumé

???
peut tu nous en dire plus ???

- roles définis par l'utilisateur

???
peut tu nous en dire plus ???

- gouverneur de ressources
- attribution de priorités (optionel)

Disponible à partir de 2008.

A +

[Halloula]

ben,moi enfait j'ai travaillé avec sql-server une seule fois,juste lors de l'installation d'un NIDS
(snort) et ce dont je me souviens (si mes souvenir sont excacts) sql_server ne donnait pas d'interface graphique,du coup on a du utilser une autre base pour la gestion des alertes et le stockage des données realtives à ses alertes ect..
parc contre orcal offre cette option avec oracle froms developper,et dailleur qui ressemble assez au vb,dans la creation des convas(je parle uniquement sur le point de vu ajout bouton ect)

[orafrance]

Personnellement je trouve le prix de la licence Oracle prohibitive, c'est plutot un produit pour les grands comptes comme les grosses banques, les grosse administration,...

En terme de coût il n'y a pour ainsi dire pas de différence à iso-fonctionnalité... sauf qu'Oracle permet de faire l'économie des licences OS si nécessaire. Oracle est reconnu depuis 2-3 ans comme étant le meilleur rapport qualité prix si on l'associe à Linux d'après TPC-C
http://www.oracle.com/solutions/perf...e-se1-tpc.html

Pour Oracle à ma connaissance, il n'y a que SQL Worksheet et TOAD ( payant ) tandisqu'avec SQL SERVER on peut créer une table ou des tables, requêtes comme avec Access.

Depuis la 10g Oracle propose une console Web très compléte mais je ne peux pas encore comparer avec SQL Server que je découvrirais plus avant incessamment

Une chose dont il me semble on n'a pas parlé c'est PL-SQL d'Oracle : un peu rebutant au départ. Je trouve personnellement que Transact-SQL est plus simple, et il y a une aide en ligne très bien faite de Microsoft.

il me semble qu'on a plus de possibilité de trouver des ressources SQL Server sur le net. Notamment le support qui est inaccessible chez Oracle sans délier la bourse

Sinon, je ne sais pas ce que vous appelez XML Search mais depuis la 9i Oracle intègre XMLDB qui est toute une batterie d'API pour manipuler le XML

Les grands comptes ont des données sensibles et ces données SQL Server ne peut pas les protéger comme Oracle (meme sous windows, Oracle est beaucoup plus fiable).

j'ajouterai même que les lectures disques sont plus rapide sous Windows avec Oracle contrairement à l'idée trop souvent répandu consistant à penser que Windows c'est plus simple mais moins performant

Par contre, avoir un Oracle pour gerer des petits volumes de données ou des données non sensibles est une folie et un gachi enorme (en terme d'argent et de perte de temps).
C'est vouloir tuer un moustique avec un bazooka.

Bah SQL Server aussi si tu vas pas là

Et je suis d'accord avec toi... une comparaison de valeur ne peut se faire qu'en précisant le contexte

[wondersonic]

Pour ma part, j'ai lu ce poste, extrait :

(traduit automatiquement avec un super site dont je tairais le nom )

"Par exemple - tout ci-dessus a la capacité de rendre des résultats (corrects) cohérents. Seulement un du susdit peut faire ainsi dans un environnement de charge de travail mélangé (des mises à jour mélangées et lit) d'une façon fortement simultanée(concourante). Dans l'Oracle nous employons multi-versioning et lisons la cohérence(consistance). Les autres utilisent des serrures lues partagées (qui mènera aux impasses et bloquant). Nous ne bloquons jamais sur un lu - ils bloquent fréquemment sur un lu. Ainsi, une autre caractéristique(fonction) avec une marque de contrôle(chèque) qui est pratiquement vide de sens."

En gros, ceci semblait vrai en 2002, qu'en est-il actuellement ? Sur SQL-Server, Est-ce qu'un update peut bloquer un select et réciproquement ?

ps : le site, c'est reverso.net !

[SQLpro]

Les grands comptes ont des données sensibles et ces données SQL Server ne peut pas les protéger comme Oracle (meme sous windows, Oracle est beaucoup plus fiable).

Il semble que cela soit l'inverse aujourd'hui, Oracle étant dans l'incapacité de corriger certains bugs...
http://www.databasesecurity.com/dbsec/comparison.pdf
http://searchsecurity.techtarget.com...232328,00.html
http://www.pcinpact.com/actu/news/32...litchfield.htm
Hélas les chiffres sont impressionnants du manque de sécurité des versions actuelles d'Oracle en comparaison de MS SQL Server !

Est-ce qu'un update peut bloquer un select et réciproquement ?

Tout dépend du niveau d'isolation choisit. SQL Server implémente depuis la version 2005 le niveau d'isoaltion SNAPSHOT (avec deux modes différents) ce qui permet qu'un SELECT ne soit plus en aucun cas bloquant.

Lisez l'article que j'ai écrit à ce sujet : http://www.sqlspot.com/Gerer-l-isola...nsactions.html


A +

[SQLpro]

J'ajoute, ce que fais SQL Server et qu'Oracle ne sait toujours pas faire :
les requêtes récursives dans des graphes.
Oracle a toujours été très en retard sur les points essentiels de la norme SQL, comme les jointures dont la clause JOIN n'est apparue qu'avec la version 9, alors que la norme les avaient introduite en 1992 (soit près de 10 ans de retard !).

De même les requêtes récursives ont été normalisées depuis la version 1999 de la norme et sont présente dans Sybase, IBM DB2, SQL Server et même récemment Firebird... Mais toujours pas dans Oracle qui implémente une technique propriétaire à base de CONNECT BY / PRIOR, incapable de traiter les graphes.
Exemple : http://sqlpro.developpez.com/cours/s...te-recursives/

A +

[orafrance]

Mais toujours pas dans Oracle qui implémente une technique propriétaire à base de CONNECT BY / PRIOR, incapable de traiter les graphes.

et terriblement complexe à comprendre

[SQLpro]

C'est marrant hier je viens de donner l'exemple que je cite dans ce papier :
http://sqlpro.developpez.com/cours/s...te-recursives/
un parcours de grpahe avec recherche du plus court chemin, et sur 9 stagiaires, 8 ont compris du prmier coup !

Mais peut être est-ce une question de pédagogie !!! ;-)

A +

[orafrance]

je pensais au CONNECT PRIOR d'Oracle qui n'est pas des plus simple à utiliser

[SQLpro]

Ha oui, mea culpa... Je confirme ! J'ai rien bité1 a cet ersatz de récursivité....

PS : 1 bité au sens informatique du terme (BIT = BInary digiT), c'est à dire que je n'ai pas pu mettre en BIT ce cencept !

A +

[voran]

Il semble que cela soit l'inverse aujourd'hui, Oracle étant dans l'incapacité de corriger certains bugs...
http://www.databasesecurity.com/dbsec/comparison.pdf
http://searchsecurity.techtarget.com...232328,00.html
http://www.pcinpact.com/actu/news/32...litchfield.htm
Hélas les chiffres sont impressionnants du manque de sécurité des versions actuelles d'Oracle en comparaison de MS SQL Server !

Il était question de fiabilité et les liens cités ne parle que de sécurité. Point important certe, mais plutôt la tâche des OS et routeurs. Car quand le loup atteind la base il est déjà trop tard.
Donc, ORACLE est au moins aussi fiable sinon plus que SQL Server.

[voran]

J'ajoute, ce que fais SQL Server et qu'Oracle ne sait toujours pas faire :
les requêtes récursives dans des graphes.

Ok,
Donc pour ceux qui en ont l'utilité (nombreux ? ) , il y a SQL Server.

Sinon dans la série ce que fait ORACLE et que SQL Server ne sait toujours pas faire :
Les base de données en cluster ACTIF/ACTIF : ORACLE RAC

[orafrance]

sauf erreur MSCS couplé avec SQL Server peut le faire

[gregory.broissard]

je confirme. SQLServer peut faire du Cluster Actif/actif

[Fabien Celaia]

je confirme. SQLServer peut faire du Cluster Actif/actif

Je suis preneur : comment fait-il cela ?? Quelle techno ?
Comment gère-t-il les pages en mémoire sur 2 machines séparées ?
On parle bien d'une base MS-SQL accessible depuis 2 machines spécifiques? Avec un dataserver ou 2 ?

Aussitôt prouvé, je corrige de facto mes critiques sur le sujet.

[orafrance]

il "suffit" de mirrorer l'instance clusterisée a priori.

PS : Ceci étant dit, l'intérêt est limité par rapport au cout que cela représente.

[jmguiche]

Je n'ai pas touché à sqlserver mais à sybase, il y a longtemps.

J'avoue, à l'époque, avoir été assez rebuté par l'absence de curseur (ça a due changer), les verrous au niveau page et le cascades de verrous, la faiblesse de la gestion des transactions, l'absence de cohérence en lecture... Sans parler des commandes systemes et la gestion des objets de la base qui, sous oracle, étaient en sql et dans un langage de commande sous sybase.

Tout cela faisait que pour obtenir un logiciel fonctionnant correctement en multi utilisateurs sur des transactions complexe les couts de dévellopement étaient bien plus élevés que la différence de couts des licences.

Un SGBD, c'est un outil. Il y a le cout de l'outil et le cout de son utilisation par les developpeurs ! C'est souvent oublié dans les études technico-économiques.

[SQLpro]

Ce que tu dit de Sybase versus Oracle était vrai il y a dix ans... . En revanche SQL Server qui en est un héritier direct à aujourd'hui effacé toutes ces tares et la version 2008 semble même en avance sur ce que propose Oracle...

Des curseurs ,des verrous au niveau ligne, page, extents, plage de clef... + un niveau d'isolation SNAPSHOT pour éviter les verrous, des transaction gérant les 4 niveau d'isolation de la norme + le 5e (snapshot)...
Pour les commandes systèmes : l'implémentation des vues normalisées (INFOMATION_SCHEMA) et plus de 250 vues et fonction tables de gestion...

Bref, une évolution importante ! Et qui fait qu'aujourd'hui les coûts de développement sous MS SQL Server dont de 10 à 30% moins élevés que sous Oracle.

A +

[jmguiche]

...
Bref, une évolution importante ! Et qui fait qu'aujourd'hui les coûts de développement sous MS SQL Server dont de 10 à 30% moins élevés que sous Oracle.

A +

Whaou ! Transact est au niveau de PL maintenant ?

[orafrance]

Transac propose surtout une souplesse d'utilisation que n'a pas le PL qui n'a pas su s'adapter aux nouveaux besoins (les requêtes dynamiques par exemple ou l'intégration de code DDL).

Ceci dit... ça ne me fait pas d'avantages apprécier Transact que j'ai du mal à apprivoiser