Comparaison entre SGBD

Salut,

Je connais pas Sybase, mais il y a deja un probleme dans ta question; sql n'est pas un sgbd, c'est (comme son nom l'indique;) un langage de requetes.

Si tu veux comparer des sgbd, je te conseille 2 endroits:

- Ce site ;)
- le site suivant: http://www.hds.utc.fr/~crozatst/ftp/nf17/

le dernier site est celui de mon prof de bases de donnees cette annee. Un certain nombre de documents seront inutiles (corrections d'exercices, de tp...) mais je te conseille:
access.pdf, mysql.pdf, oracle.pdf, sgbdro.pdf
qui decrivent les sgbd du meme nom. Les fichiers nx17*.pdf parlent de conception de base de donnees je crois, et web.pdf d'applications (php, java...)

Sinon si tu as des questions plus precises, n'hesite pas...

Bon courage,

Eddy

Je connais pas sybase.
Par contre Oracle est THE database et franchement SQL Server ne tiens vraiment pas la comparaison.

Un argument simple et imparable? : SQL Server ne tourne que sur..microsoft alors qu'Oracle est dispo sur toutes platformes ( MS, autres unixes et linuxes...). Résultat ; Si tu prends SQL Server et ben t'es marié avec MS pour la vie, et qui te dit que (même) si t'es content de ton WIn2000 aujourd'hui, t'en seras content ds quelques années ??
Par contre avec Oracle tu fais un export/import..et hop, t'as changé de platforme!

Si jétais à ta place, je n'hésiterais pas une seconde à choisir Oracle.

Si l'argument donné au dessus ne te suffit, il en éxistent des centaines d'autres bien qu'il soit impossible de comparer fonction par fonction : les concepts eux-meême étant si different au départ ( par example chez Oracle il est TOUJOURS possible de lire une donnée, une lecture n'est jamais bloquée par un autre utilisateur en train d'écrire - pas le cas pour tous les sgbdr ;)).
Mais honnetement, demande à n'importe quel admin quelle fiabilité il occordait aux OS Microsoft il y a 5 ans... la reponse sera rapide : aucune.
MAintenant projete toi dans l'avenir et pense comment sérieusement tu pourrais affirmer que ds 5 ans tu continueras à utiliser un OS MS en production. D'ailleur rien que le fait de devoir appliquer un Patch sur l'OS tous les 15 jours et souvent devoir redémarrer le serveur et donc la base à simplement un impacte énorme sur les performances des bases puisque toute ta mémoir est vidée à cet instant.

En réponse à MP, je lui dirait seulement qu'il y a autant de difference entre oracle 7 et 9i qu'entre Windows 3.11 et WInn 2003.... alors comparons ce qui est comparable (SQL server néxistait d'ailleur pas à cette épok lol ).
Concernant les outils de backup, alors là, je préfere en rire car dire qu'Oracle n'est pas bon en backup/restauration, c''est quand même poussé le bouchon un peu loin maurice !! Meme chose concernant la doc : la doc Oracle est tout simplement sensationnelle (bien qu'en anglais) et dispo sur plein de sites avec également un service support paerformant et réactif et surtout des centaines de forums de haut niveau.

A toi de voir si tu veux investir dans un produit sur lequel tu puisse compter, performant, leader depuis des années, où tes données seront sécurisées ou alors sur un produit que tu seras potentiellement obligé d'abandonner pour differeente raison ( OS trop pourri, MS décicdant de ne plus faire de développement dessus car pas asser rentables - d'ailleur pas d'évolution depuis la version 2000 alors qu'Oracle sort environ une version majeur par an- ETC ..... ) et pour lequel tu devras migrer ton application et tes données.

Bonjour à tous

Un peu de calme les amis Oracle. Mon but n'est pas de caler Oracle du tout. C'est un produit respectable et il y a beaucoup de gens qui l'utilisent. Et oui j'ai vu aussi des améliorations dans leur produit version 9i. Mais voilà quelle est mon impression. Avant la compétition de Microsoft, Oracle se traînait les bottes sur les standarts SQL (en autres les jointures ansi). Il a fallu attendre deux versions Oracle (8 et 9)après que Microsoft l'ait introduit.

En ce qui concerne la question de l'OS quand SQL Server roule sur un serveur dédié on n'a pas de problème. On a beaucoup de clients qui roulent beaucoup de serveurs SQL Server depuis des années sans arrêt. On n'a pas à patcher un serveur SQL pour Outlook, ou Internet Explorer ou d'autres bébelles qui ne roulent pas dessus. On ne parle pas d'un cas de poste de travail. Mais on a raison de dire que dans en environnement ou on ne veut pas de période de maintenance que c'est ennuyeux. Remarque que dans de tels environnement on règle cette question avec du clustering.

En ce qui concerne les backups / restore désolé de vous contredire. La processus est pas mal compliqué sur Oracle. Sur SQL Server un restore de BD n'exige de n'avoir personne sur la BD et de passer qu'une commande de recouvrement. Pour revenir en arrière à un point précis dans le temps, ce n'est guère plus compliqué. On ne se retrouve pas avec x fichiers d'archivelog à gérer. Je n'ai pas dit que le processus de backup restore d'oracle est pas bon, j'ai juste dit que c'est compliqué, et ça c'est pas pareil. Je suis persuadé que le processus de backup / restore d'Oracle doit être bon, puisqu'il est utilisé par des entreprises sérieuses et c'est la cas aussi de Microsoft SQL Server . SQL Server tourne aussi dans des grosses entreprises pour de grosses applications.

Voir les études de cas : http://www.microsoft.com/resources/casestudies/FindCaseStudyResults.aspx?ProTaxID=1273

Les deux produits sont des produits matures et fiables, et le débat n'est pas là. Le débat doit porter sur l'adéquation entre vos besoins en évolution, la facilité de travail avec l'outil, et la grosseur de l'implantation que vous voulez faire. Si vous voulez faire roulez la bourse de Paris avec Oracle, vous ne faites pas un mauvais choix. Vous aurez aussi le moyen de vous payer les DBA, les coûteuses licences, et vous aurez l'avantage de choisir la plate-forme. J'ai eu de la formation d'un gars Oracle qui a été DBA en chef la bas et c'est ce qu'il y avait. On peut aussi faire du petit avec Oracle, mais c'est un plus compliqué, à moins de mettre l'archivelog de côté, ou de se programmer des processus de ménage de ces fichiers.

Installez SQL Server puis installez Oracle et configurez-le cela en dit long sur cet aspect. SQL Server offre des procédures de maintenance automatique, Oracle offre-t-il quelquechose de ce côté maintenant ? Je ne le sais pas.

En ce qui concerne le travail investit dans Oracle, il faut départager ce qui se fait au niveau du SGBD, et des applications Oracle, parce qu'Oracle c'est aussi une boîte d'applications. La partie applications Oracle draîne pas mal de gros d'investissements, et Oracle veut faire déborder ses affaires de ce côté (ex. ses tentatives d'acquisition de JD Edwards).

Microsoft a une TRES grosse équipe de développeurs à plein temps sur le développement de SQL 2005, alors si on as appris qu'ils avaient l'intention de ne plus investir dans SQL Server, dites moi où on a pêché cela. Et ce n'est pas dans les fonctionnalités qu'ils annoncent qu'ils semblent avoir l'intention de mettre les freins. En ce qui concerne SQL 2000, il y ont ajouté les services de notifications et de reporting.

Tous les gros développeurs de SGBD investissent massivement dans leur produits et la plupart auront des fonctionnalités toutes les plus intéressantes les unes que les autres. Pourquoi ? parce que le SGBD est un excellent moyen d'assurer sa présence dans l'entreprise. Tous aussi essaient de combler les lacunes comparatives qu'ils ont par rapport à leurs concurrents ou les distancer davantage dans leurs avantages. Donc souvent les impressions acquises il y a quelques années ne valent plus aujourd'hui. Par exemple DB2 essaie de rendre plus simple l'admin. de sa BD, et je crois que Oracle aussi, mais ils ont du chemin à faire de ce côté. Quand tu regarde le paquet d'options statiques et ésotériques qu'on trouve dans le fichier init d'Oracle, et l'évolution d'Oracle tu comprends deux choses: Il s'agit d'un gros produit bâtit sur une ancienne architecture. On investit sans doute dessus mais ils ont a vivre avec ce qu'ils ont fait au départ. C'est vrai que le versionning d'Oracle (lire des données antérieures à celles qui sont en train d'être modifiées par une transaction) est parfois un avantage (dans les rapports) et aussi un inconvénient. Il faut avoir eu des problèmes esotériques de rollback segments pour comprendre. Es-ce moins pire maintenant avec Oracle 9i ? Je n'en sais absolument rien. Nos connaisseurs Oracle peuvent se prononcer là dessus.

Microsoft offrira une fonctionnalité équivalente activable sur option dans SQL 2005. Ça reste à comparer.

On peut débuter avec Microsoft SQL Server et faire beaucoup de chemin avec sans problème. C'est tant mieux si les SGBD ont de plus en plus de fonctionnalités à offrir à toutes sortes de prix et avec toutes sortes de niveaux de complexité. Pour notre part on développe de grosses applications avec SQL Server, et les petites y sont aussi faciles à développer. Quelqu'un qui débute en SGBD se sentira très à l'aise avec SQL Server. L'outil est élégant et performant. Il faut pas comparer les produits à partir du passé car il ont évolués.

En ce qui concerne la perennité de ces produits ces sont tous des produits qui sont là pour rester (SQL Server, Oracle, DB2) et ils vont tous conserver des parts de marché suffisantes pour continuer à progresser, avec leur supporters passionnées.

Bonjour,

Continuons donc notre comparaison Oracle/sql Server. J'avoue être fan d'Oracle (ceçi explique celà) et malheureusement ne pas ( vouloir) connaitre SQL Server suffisament sur certains points. D'autre part, je galere chaque fois à trouver des bon site, des bonne docs, des "white paper" sur SQL SERVER ce qui est dautant plus découragant. Passons.
Pour reprendre, remarquez dans un premier temps que je parle uniquement de la version 9i, version sortie il ya maintenant pas mal de temps et que je ne parlerais même pas de la version 10G (sortie il y a environ 6 mois) car je ne la connais pas assez. Contrairement à vous qui parlez déjà de la 2005 pas encore dispo.

Déjà, J'ai quand même un doute sur le fait qu'il puisse y avoir des Server Windows avec SQL Server dessus qui n'ont pas redémarrer depuis des années. Si c'était le cas, je suppose qu'ils auront de toutes façon à rebooter pour mettre la 2005.;)
En parlant de Clustering, Oracle le supporte depuis la fin des années 80, avt même que NT n'éxiste!
Cela me fait d'ailleurs penser à autre chose d'hallucinant sur SQL Server : le fait que lorsque vous voulez installer un nouveau Serveur SQL sur votre serveur, le programme d'installation vous demande d'arrêter tous vos autres Server SQL (sympa pour les base en prod, ça!)

Pour les backup/restaurations, soyons honnête : la comparaison est impossible, tellement Oracle est en avance.
UN peu compliqué? .. peut être mais le résultat obtenu n'est pas le même!
Oracle permets (entre autre) :
1. D'utiliser la fonction Flasback : ce qui permet à UNE session (pendant que les autres utilisateurs continuent à travailler normalement) de revenir en arriere et donc par example de voir une table telle qu'elle éxistait il y a une heure (par example) pour eventuellement corriger par la suite d'éventuelles erreurs.
ça c'est ce que l'on appelle multiversionning et "read consistency".
J'avoue avoir des doutes sur ce que MS proposera...mais à voir.
A propos de versionning, car ça c'est un point enorme, pourquoi ne pas faire le test suivant :
create table test (a numeric) --> créer une table
insert into test values (1) --> insérer des données
Commencer une transaction :
begin transaction
update test set a=2
Maintenant, allez sur un autre poste ou lancer une autre session et faites :
select * from test
Mettez le chronometre en route.
Résultat : sur MS SQL Server, vous attendez indifinement et ce uniquement pour pouvoir lire une donnée, sur Oracle la réponse est immédiate.
Que montre ce test ? que MS (et d'autre, tel que DB2) a choisit la facilité alors qu'Oracle non. Résultat : concepts completement différent, retard irratrapable des autres.
De la même façon, SQL Server pratique l'escalade de locks, car les lock sont des précieuses ressources sur MS et qu'il faut les économiser. Résultat : des données sont lockées sans raison.
Sur Oracle , avoir un lock ou 1000 "coute" autant : absolument rien--> L'application est donc plus disponible.

3.Pour revenir au pb de restauration :
Sur Oracle, on peut arrêter la base et restaurer l'ensemble à une date/heure inférieure

4.Mieux : ON peut aussi faire une restauration d'un tablespace jusqu'a un point dans le temps.
C'est à dire : tous les utilisateurs reste connectés, on rends seulement indisponible certains fichiers ( ce qui ne bloque pas les autre) puis on restaure le(s) fichier(s) en cause jusqu'à la date/heure choisie.

5. On peut analyser les fichiers log pour voir quelles modifs ont été faites et eventuellement faire les modifs inverses.
On récupere aussi le login utilisateur de la personne qui a fait la modif (rien a voir avec les possibilité d'Audit, qui s'ajoutent aussi à celà).

D'autre pts sur backup/restauration :
- Les fichiers redolog (ou transactions log pour MS) sont mirroirable sur Oracle.
- Ils sont archivés automatiquement sur Oracle et manuellement sur MS ce qui implique l'utilisation de script ( pb en cas de modif de charge)
- SUR MS Sql, en cas de perte de MSDB, il est nécessaire de récuperer le CD pour recréer MAster.
Pour Oracle : un backup contient TOUT.
- Oracle peut restaurer par block : si un block est corrompu, il n'est pas nécessaire de restaurer le fichier complet. ON peut uniquement restauré le block ( taille type 8ko), pendant que le reste du fichier est utilisé.
ETC.....

Les possibilités sont infinies et automatisable ce qui permets d'avoir le moins possible d'intervention utilisateur et donc de risque d'erreur.

Pour répondre rapidement sur le fichier init d'Oracle : il permets d'avoir la main sur de nombreux parameteres dont l'allocation cyblée de mémoire. On ne peut pas sérieusement critiquer le fait qu'Oracle soit hautement configurable et laisse la main sur de nombreux parametres de tuning.
De même ce fichier init existe maintenant en binaire, ce qui permets -entre autre- de modifier le montant de la mémoire allouée à chaque "pool" Oracle sans redemarrer la base ( toujours un souci de disponibilité maximum).
Les rollback segment sont remplacés depuis la 9i par un tablespace d'undo et les erreurs presque chose du passé ( dejà le fait qu'elles éxistent auparavent était seulement lié à de la mauvaise administration).

Je pense sérieusement qu'Oracle et SQL Server ne joue pas dans la même catégorie, et les points en faveurs d'Oracle sont vraiment nombreux.
De ce fait la comparaison ne tiens même pas et on pourrait passer des jours à le prouver.C'est pourquoi j'avais ds un premier temps uniquement apporté comme point fort le fait qu'Oracle est dispo sur "tous" les OS.
Que seront ces bases SQL Server, quand tout le monde changera d'OS ? (peut être pour LInux... ?)

Plus d'info (objective ;) ) sur : http://otn.oracle.com/products/manageability/database/pdf/SSOracletechcomparison1.pdf

Je suis tombé sur cette discussion lors de recherches pour connaître les différents avantages/désavantages des différents SGBDR (pour ne pas être cantonné aux préférences de mes formateurs et/ou des entreprises, et avoir une vue plus large).
Vous avez bien argumentés sur les comparaisons oracle/MS SQL, bien que ce soit (forcément) assez long, vos commentaires restent agréables, et bien sûr, en pratiquement 6 ans d'existence, beaucoup doivent être obsolètes...
Juste au cas ou, je transmet ici un lien trouvé qui cite les avantages et désavantages de ces SGBDR et de bien d'autres. Si quelqu'un peut infirmer/confirmer/corriger les affirmations qui y sont, ce serait probablement une bonne chose (je n'aime pas me fier a une seule source, surtout quand je n'ai aucun avis/connaissances préalables sur la question)? Sinon, cela permettra sûrement aux fans d'un ou l'autre système de réviser leurs opinions au sujet de leurs concurrents ^^
http://fadace.developpez.com/sgbdcmp/

Vous noterez qu'on retrouve d'ailleurs certains arguments qui étaient doutés (si l'on peut dire, le mot exact vient de me sortir de l'esprit...) , comme la supériorité des flashback d'oracle et son grand nombre de fonctionnalités, ou pour le côté MS SQL, sa simplicité d'administration accrue et sa grande fiabilité... (je rappelle que je ne fais que me fier a un avis extérieur (même si developpez.com ne m'as jamais induit en erreur jusqu'à aujourd'hui), et que j'ai besoin d'autres avis pour savoir à quoi m'en tenir exactement... Je n'affirme rien, je ne fais que citer)

Penser aussi à PostgreSQL et BerkeleyDB qui ont d'excellentes performances.

http://www.postgresql.org/
http://www.postgresql.com/
http://www.sleepycat.com/

J'ai fait une comparaison entre ces SGBD. J'ai utilisé Sybase, SQL Server et Oracle. J'ai fait une comparaison théorique entre PostgreSQL et SQL Server.

Si le multi-plate forme est ton premier critère, aussi bien t'enligner sur Oracle/Sybase mais ils sont dispendieux. Je ne sais pas si ils sont en train de reviser leur mise en marché. J'ai entendu dire que oui dans le cas d'Oracle.

SQL Server et Sybase se ressemblent beaucoup sur l'interaction avec la base de donnée. SQL Server est un descendant philosophique de Sybase, en ce sens qu'il est né d'une association entre Microsoft et Sybase qui croyait ainsi se tailler un avenir via un entrée par la micro-informatique (l'équivalent micro d'Oracle à la même époque était affreux). Depuis ils ont mis fin à leur association, Microsoft a réécrit entièrement l'engin, qui roule très bien, et possède un excellent optimiseur de requête. Je ne sais pas si Sybase a bien évolué depuis le temps.

Le langage de requête de SQL Server est très bien et est très prometteur pour la version SQL 2005. Il règle plusieurs problèmes qui datent depuis des lunes avec le langage SQL. Ce qui est bien avec SQL Server c'est qu'on peut indiquer précisément à l'optimiseur comment résoudre sa requête, lorsque l'optimiseur n'y arrive pas. Avec Oracle7 il y a des indices qu'on peut lui fournir, mais il n'écoute pas toujours. Avec Oracle8 et au dessus c'est à réévaluer. Avec Sybase je ne sais pas. Avec PostgreSQL la façon de contraindre l'optimiseur ne nous garantit pas le résultat.

En ce qui concerne la performance, SQL Server se débrouille assez bien, même avec des très grosses BD.

Au sujet de PostgreSQL, il ressemble à Ingres, avec des concepts intéressants. Cependant l'ordre de grandeur des investissements faits dans l'optimiseur de requête est faible en comparaison de ce que les produits commerciaux font. Donc comment se comporte son optimiseur face aux requêtes complexes est à démontrer.

Si j'insiste tant sur l'optimiseur, c'est que le gros de mauvaises performances des applications utilisant le langage SQL viennent de mauvaises optimisations de requêtes. Un optimiseur qui rate plus souvent son coup te donnera plus de maux de tête.

Une requête complexe bien optimisée fait plus rapidement le travail que les milliers de petites requêtes qu'il faut faire à la place. De plus cela t'évite de programmer les boucles de code et les structures plour stocker des résultats intermédiaires. Donc si ton serveur est capable faire l'algorithme d'obtention des données à ta place, c'est payant. Pour ça il faut qu'il soit capable bien optimiser ses requêtes.

SQL Server possède pour diagnostiquer la partie requêtes d'une application, un excellent traceur de requêtes (avec filtres, plan d'accès, requêtes durées, deadlock etc etc. SVP). J'ai commencé à chercher l'équivalent dans PostgreSQL. Il ne semble pas y avoir d'outil équivalent. Un tel outil est essentiel dans le déboggage d'applications client-seveur. Cela permet qu'on puisse faire de la recherche de problème dans une application, sans qu'on ait à utiliser un déboggueur.

J'ai cessé de travailler avec Oracle depuis la version 7. A l'époque il fallait acheter des produits complémentaires si on voulait faire facilement une trace des requêtes au serveur. En gros, sans cet outil, il fallait pas mal travailler pour faire l'équivalent du diagnostic qu'on arrive à faire avec SQL Server. Si on a besoin d'envoyer un scénario de trace à un client, c'est très facile avec SQL Server.

SQL Server offre des outils de gestion très faciles à employer avec un céduleur de tâches de maintenance de la BD. Microsoft à l'avantage de n'avoir qu'à développer que pour Windows... Oracle et Sybase ont de moins bon outils. Peut être Sybase s'est amélioré depuis.

Si tu as un petit environnement, MSDB c'est la version gratuite de SQL Server, sans ses outils graphiques (mais il existe du freeware qui le fait). MSDB est parfaitement compatible avec SQL Server parce que c'est SQL Server, avec un barrure sur la performance, à partir de cinq requêtes actives en même temps. En gros ça peut supporter une vingtaine d'usagers en même temps avec une très bonne performance. Ensuite c'est fait exprès pour ne pas aller trop vite. Microsoft veut vendre sa BD si l'application et votre clientèle sont gros. Un truc : vous vous achetez la version SQL Server developper edition, cela vous donne accès à tout comme développeur, et dans un environnement de développement. POur déployer l'application, vous pouvez utiliser MSDE si le client est petit, ou SQL Server Standart Edition s'il est gros.

Un dernier point extrêmement important. La documentation. SQL Server possède une documentation en-ligne supérieure à ses concurrents. Cela est très important pour avoir le pourquoi et le comment de ce que l'on essaie de faire. Il y a beaucoup de sites pour avoir de l'aide et le SQL Server Magazine.

Je crois que Oracle doit aussi avoir une grosse communauté de développeurs.

La doc. de PostgreSQL est moins invitante.

SQL Server est de loin le meilleur produit jamais développé par Microsoft. C'est un produit très stable. On peut trouver de temps à autre des gens qui se plaignent, mais c'est l'exception. Je crois pour ma part qu'il s'agit de gens qui ont des problèmes de compétence avec SQL Server, ou plus simplement avec le SQL.

Sybase est sans doute plus "user-friendly" que Oracle, mais on s'inquiète un peu pour son avenir, sa part de marché semblant ne pas grossir très vite.

PostgreSQL a une communauté intéressée à le faire progresser, il est vrai, mais je pense qu'il est douteux qu'il arrivent à le faire progresser aussi vite que les gros joueurs tels Oracle, Microsoft SQL Server, IBM (db2), tout simplement parce que ces trois derniers sont en grosse compétition, et qu'ils n'ont pas le choix d'investir leur revenus dans la progression de leur SGBD respectifs.

Par exemple Oracle 10g est un gros investissement d'Oracle pour simplifier l'utilisation d'Oracle qui a toujours été pas mal plus compliqué à utiliser que SQL Server. A la base il a une plus vieille architecture avec beaucoup de boutons d'ajustements si on peut dire. Oracle est conscient de ce désavantage et essaie d'y palier. IBM travaille aussi en ce sens. La raison : Microsoft accroît sa part de marché à leur dépends. Mais dans les trois, le marché grossit, car les SGBD relationnels sont de plus en plus utilisés.

SQL 2005 (la version bétâ) offre déjà pas mal de fonctionnalités qui vos assister le développement de services Web, le développement de requêtes, les traitements asynchrones, letraitement du XML et le dévelopement de code serveur. Je crois que les compétiteurs ont aussi des offres à faire de ce côté.

C'est un marché en bonne santé. Comme développeur cependant et comme responsable du soutien je me sens plus à l'aise avec SQL Server.

En dernier lieu, pour nous francophones, Microsoft supporte admirablement bien la langue française, aussi bien dans la Doc, que dans le logiciel, et surtout dans les règles de comparaison des caractères. Par exemple il est capable de rechercher dans la BD en faisant abstraction de l'accentuation et de la casse (comme Sybase aussi). Essayez de faire la même chose de manière performante avec PostgreSQL, Oracle ou DB2.

On voit que Sybase / Microsoft SQL Server sont des produits bâtis sur une architecture plus récente. Les autres ont dû évoluer avec ce qu'ils avaient à la base.

En dernier l'aspect intégrité/recouvrement des données est très simple avec SQL Server (on peut faire du point-in-time recovery) très facilement. Le recouvrement Point in time est souvent requis lorsque les usagers ont fait des erreurs de manipulation dans les productions de leurs application.

Sybase permet quelquechose de similaire, mais je ne sais pas si il est aisé de le faire. Oracle aussi, mais c'est plus compliqué. En ce qui concerne PostgreSQL il n'en est pas fait mention dans la doc. Je dois dire à leur décharge qu'il me reste sans doute à approfondir mes lectures sur PostgreSQL. Mais à date, il ne semble pas y avoir de gros paragraphes la dessus. Ça me donne à penser que ça n'existe pas sur cette plate-forme, mais c'est à vérifier.

Je ne parles pas de MYSql car il s'agit d'un produit qui a été conçu pour des besoins simples, mais à mon point de vue il est en dessous des autres, à moins que ce qu'on veut faire soit assez simple et ne risque pas de trop se compliquer.

Les 4 type de bases de données sont bien pourvues en types de données. Pour les champs très longs, il y a les types text et image de SQL Server/Sybase. Les champs de type text supportent une recherche par opérateur like (pattern matching) (mais non indéxé) comme le disait l'auteur précédent. Les champs de type text supportent le style de comparaison de caractères de SQL Server.
Oracle offre la notion de LOB et CLOB probablement pour les mêmes raisons.

La prochaine version de SQL Server SQL 2005 supporte aussi la notion de colonnes de type XML. Ces champs seront aussi indexables et exploitable par des primitives XML. Si tes données CAO sont exportables en XML et qu'il y a des possibilités de les exploiter, ça peut devenir intéressant.

La prochaine version de SQL Server, SQL 2005 introduit aussi des extensions au SQL extrêmements intéressantes dont les Common Table Expressions, les générateurs de valeurs séquentielles dans les résultats de requêtes, et des services broker (des trucs qui permettent le traitement distribué et asynchrone au moyen de queues de messages entre les serveurs SQL). Il y a aussi les reporting Services (récemment introduit dans SQL 2000). Ce truc permet de produire des rapports Web très riches en fonctionnalités, exportables en différents formats (.pdf excel xml), cédulables, sur demande ou automatique paramétrisables etc...

Si j'étais à ta place, je n'hésiterais pas un instant à choisir SQL Server, sans compter que SQL Server est disponible en version gratuite (MSDE). Cette version diminue automatiquement sa performance passé 5 requêtes simultanées, mais c'est la même chose que la version standart. Evidemment si vous un petit projet ou un petit client, c'est une aubaine. Le hic c'est une version sans outils d'administration graphique. Cependant des outils d'administration gratuits existent pour MSDE. De toute manière l'administration par commandes SQL est relativement simple (backups / restore), même à partir d'une application.

C'est vrai qu'Oracle a investi en ingénierie dans leur SGBD plus que n'importe qui d'autre.

Le SGBD Oracle est l'un des logiciels qui totalise le plus de jour/homme de travail.

Microsoft n'a débarqué que récemment dans les bases de données, et avec un sacré retard. :-)

Bonjour,

En réponse à notre dernier interlocuteur.

Ne pas vouloir connaître une plate-forme n'est pas sage professionnellement. Les autres plate-formes ont parfois de bonnes idées et cela permet une comparaison plus nuancée en fonction de l'adéquation entre l'offre (ce que la plate-forme offre) et les besoins (les problèmes applicatifs qu'on doit résoudre).

---L'information sur SQL.

Elle ne manque pas : Voici d'excellents sites de départ:

http://www.winnetmag.com/SQLServer/
http://www.sqljunkies.com

Le site d'acceuil SQL Server chez Microsoft offre toutes sortes de renvois dont des études de cas, et des grosses implantations SQL Server.

http://www.microsoft.com/sql/
Et pour les white paper / astuces SQL Server :
http://msdn.microsoft.com/sql/

En plus il y a l'excellente documentation électronique de SQL Server : Books Online qu'on peut directement récupérer de www.microsoft.com/SQL. Elle est en format .CHM

Je ne reproche à personne d'être fan d'une technologie de BD particulière, les technologies de BD son devenues très intéressantes depuis les dernières années. Donc je peux vous comprendre d'être fan d'Oracle, moi même je fais encore des découvertes passionnantes sur SQL Server malgré mes dix ans d'expérience sur cette plate-forme. Chaque plate-forme offre ses avantages et ses manières de faire.

---Au sujet de l'installation de SQL Server.

Installer un serveur SQL2000 ne demande pas d'arrêter l'OS et si votre intention est d'installer une nouvelle instance, il ne demande pas d'arrêter les autre instances SQL Server. Je l'ai déjà fait et le fait encore régulièrement. Etant de background Oracle, j'imagine que votre intention est d'installer une instance SQL supplémentaire. Avec SQL Server c'est moins nécessaire car un seul moteur SQL Server en mémoire supervise plusieurs databases. Le moteur Oracle est spécifique à un database. C'est une différence avec laquelle les experts des deux côtés savent tirer partie. De plus deux instances SQL Server peuvent rouler à des versions et services packs différents. Peut être que votre impression provient d'une expérience passée avec SQL7 ou sur NT.

En parlant de Clustering, je reconnais qu'Oracle se vante d'offrir bien des option$$$ à ce sujet. Je pense que leur offre a ses mérites techniques, et qu'elle est aussi assez dispendieuse. Cependant en ce qui concerne les grosses implantations SQL Server (présentées sur le site de Microsoft) il y a des cas dont l'envergure est telle que 98% des développeurs n'auront jamais à toucher.

---Au sujet des backups restore.

Pour ce qui est des backups restore, je réaffirme que la comparaison se fait très bien avec Oracle. SQL Server rend très simple la restoration à un point dans le temps. L'archivage des logs de génère pas une multitude de fichiers car il n'y a pas de nécessité d'avoir des redo log. En fait l'archivage des log est simplement l'affaire d'une simple commande SQL dont l'exécution est cédulé par l'agent SQL (un service qui roule en parralèle avec SQL Server). La commande SQL et sa cédule peuvent être générée via l'interface graphique de Entreprise Manager. La destination du backup partiel peut se combiner au fichier de backup total ou à un fichier de backup partiels, car SQL Serveur peut mettre plusieurs backups dans un même fichier et s'y retrouver. De même lors du restore il se rappelle où il a mis ses backups et génère les requêtes appropriées pour revenir à la version désirée de la base de donnée.

---La récupération de master / msdb.

Votre prétention à savoir qu'une perte de MSDB demande de reconstruire la base de données master est complètement contraire à mon expérience. Cette base de données se restore comme les autres. En théorie je le savais et j'ai même essayé au cas en simulant sa perte.

La reconstruction de la base de donnée master n'est requis que si l'on en perd les fichiers. C'est la même problèmatique que de perdre les fichier contrôle avec Oracle mais c'est plus simple sur SQL Server. SQL Server ne garde que peu de lien entre cette BD et les autres, de sorte que le retour en arrière sur master n'empêche pas l'instance SQL de fonctionner. Une fois les fichiers récupérés (soit par une copie valide faite après installation ou par reconstruction) on réapplique le backup le plus récent qu'on a. Même là on peut s'en tirer facilement sans backup très récent. La reconstruction du fichier master se fait en deux clic de souris. Il n'y rien là qui demande de s'arracher les cheveux. Une fois les fichiers reconstruits (une affaire de quelques minutes) on réapplique nos backups les plus récents. Il faudrait être pas mal négligent pour ne pas avoir de backup de BD, surtout qu'il est possible via l'interface graphique de mettre en place les backups automatiques avec gestion des fichiers sans écrire une seule commande SQL ou script.

---Le retour en arrière et l'intégrité.

Si Oracle vous permet de revenir en arrière avec la fonction flashback (par exemple revenir en arrière d'une heure), c'est à condition que les fichiers qui contiennent cette information soit assez gros. Si une période de grosse activité produit de l'information en excédent de la capacité de ces fichiers un retour en arrière sera j'imagine impossible.

Avec SQL Server on procède simplement à un restore du database sous un autre nom de BD avec du point in time restore du fichier de backup (total + partiel). C'est assez rapide car il n'y a pas de nécessité à installer une autre instance comme sous Oracle car SQL Server est multi-database. Dans ce cas là tu est sûr de trouver l'information. En ce qui concerne la possibilité de corriger une erreur passée, vous voulez sans doute parler de la possibilité de la diagnostiquer, de retourner en arrière et de reprendre le traitement. J'imagine mal quelqu'un affirmer être en mesure de jouer dans une table et de ne pas tenir compte que les modifications à cette table dépendent de d'autres règles d'intégrité référentielles.

SQL Server permet une restoration partielle d'une base de données par filegroup et les filegroup ainsi restorés sont disponibles. Si on parle au futur (SQL 2005) il sera possible d'accèder la base de données encore plus rapidement avant même la fin du backup, mais cette affirmation me laisse perplexe car elle doit imposer des restrictions d'accès. C'est à voir...

---SQL Server 2000 n'offre pas la possibilité d'examiner le log, mais des produits complémentaires le font et ils sont relativement bon marché.

En ce qui concerne la gestion des backups totaux et des logs aucun script n'est requis. Peut-être que votre situation l'a requis et si vous daignez me l'expliquer il me fera plaisir d'y répondre. Sur SQL Server tout est aisément automatisable, sur Oracle on peut automatiser pas mal de trucs mais peut-on le faire aisément ? Après bien de la formation sans doute....

En ce qui concerne la restoration d'un block, vous avez parlé de bloc corrompu. D'habitude sur SQL Server un tel problème survient à cause du hardware (des contrôleurs qui on des write cache sans tolerance aux pannes). J'espère que ça n'arrive pas sur Oracle que pour une raison autre que le hardware. Mais je parirais fort que ceux qui se paient des DBA capables de le faire des restoration de block sont aussi capable de se payer un raid-1 qui prévient ce genre de problème sans casse-tête. C'est bien théorique comme avantage. SQL Server est capable aussi de corriger lui-même certains problèmes d'intégrité dans les index, sans passer par un restore et en même temps que tout le monde travaille.

---Le versionning est ses réels avantages.

En ce qui concerne le versionning, malgré ses avantages, il vous permet aussi de lire des données qui ne sont pas à jour, c'est à dire qu'elles réflètent le passé qui est en train d'être modifié au présent. Dans le contexte d'une transaction, votre code prendra donc une décision sur des valeurs passées au lieu que le serveur vous fasse attendre juste un peu la fin de la transaction pour vous laisser lire quelquechose qui est à jour. Le "read consistency" est au passé, pas au présent. Il faut en tenir compte dans sa manière de coder. Il existe sans doute un truc Oracle pour contourner ce genre de problème, mais c'est le comportement par défaut.

Sur SQL Server 7-2000 on peut lire quelquechose de verrouillé via l'option noLock au niveau du Select, mais ce n'est pas aussi intéressant que le versionning. On peut aussi de faire un snapshot de l'image des données par un select avec l'option into pour créer une table temporaire dans tempdb. Dasn un cas ou l'autre, quand le rare besoin se fait sentir on a des solutions.

Nous avons une expérience valable avec une GROSSE application bi-serveur qui nous montre que les SGBD SQL Server ou Oracle desservent bien l'application et avec une performance comparable. Nous avons fait notre développement avec Oracle premièrement (requis par certains clients) puis nous l'avons adaptée pour SQL Server (requis par d'autres clients). Le port à consisté à écrire des triggers / stored procedures compatibles pour SQL 7. A mon avis, sachant ce que nous utilisons avec SQL Server, l'inverse aurait été plus difficile. Les triggers SQL Server sont After trigger avec accès à toute l'information modifiée dans des pseudo-tables. Oracle aurait requis des After-row qui ont des contraintes d'accès aux données (mutating tables) qui nous ont donné des casse-tête. Le jour où Oracle permettra d'écrire des After trigger style sql server, ce sera un gros plus pour lui.

En ce qui concerne les rollback segments (chose du passé), je suis allé au support d'Oracle, il ont demandé toutes sortes de trucs, les paramètres des tablespaces, et on fait tracer des tas de trucs sur Oracle sans succès. On a résolu le cas avec des rollback segments très très gros, puis un jour le problème s'est résorbé. J'ai posé la question à des DBA Oracle plein temps qui étaient bien embêtés compte tenu des informations que je pouvais leur fournir. Personne n'avait d'explication valable à ce phénomène sinon que le versionning était évidemment en cause (erreur snapshot too old). Je parirais fort que cette erreur risque encore de survenir même avec la technologie actuelle, car il s'agit d'une question de volume de transactions passées.

---Les verrous

Votre test à propos du versionning je le connais bien. Nous avons une version d'application qui supporte à la fois SQL Server et Oracle. En passant c'est se leurrer de croire le versionning élimine tous les deadlocks. Il en réduit toutefois les chances si une des opérations participantes au deadlock est une lecture. Cependant toutes les opérations de modifications sont toutes aussi sujettes à faire des deadlock entre elles sur n'importe quelle technologie de BD.

Votre test quoiqu'exact est très loin de la réalité d'une application réelle. Depuis quand on commence une transaction sans la finir ? Ne cherche-t-on pas non plus à faire les transactions les plus petites possibles car même sur Oracle une donnée modifiée dans une transaction demeure inaccessible à une autre modification tant que la transaction ne se termine pas.

Sur SQL Server votre select attendra jusqu'au commit c'est à dire une micro-fraction de seconde plus tard, et sur Oracle il n'attendra pas. L'escalade des locks sur SQL Serveur survient seulement si une proportion significative des données est bloquée et elle est variable en différents endroits de la table. Par exemple si une porportion significative de la page est verrouillé, il peut l'augmenter en verrou de page, sinon les verrous par rangées demeurent. Si une grosse proportion de la table est verrouillée, le verrou s'étend au niveau de la table, mais SQL Server fait cela de manière ordonnée, et son extension de verrou ne sera pas acquise avant la libération des verrous existants. Il s'agit d'un compromis acceptable, qui rend l'opération massive très performante de manière à laisser le chemin libre aux autres le plus rapidement possible. Nous avons des applications totalisant des millions de lignes de code avec SQL Server, et les rares causes de deadlock proviennent du fait d'un plan d'accès défectueux qui demande un balayage de table dans une opération de modification qui aurait dû utiliser un index. Quand je dis rares, je parle d'une fois par an et ils sont dûs à de nouveaux développements.

---La mécanique des locks sur oracle est basée sur des slots au niveau des block qui limitent le nombre de transactions possibles simultanées sur le block.

Dans un cas comme dans l'autre notre expérience nous montre qu'on peut développer des applications d'envergure avec un effort très équivalent puisque nous supportons le même code source pour les deux plate-formes. Il est rare qu'une plate-forme exige des efforts supplémentaire sur l'autere. Une fonctionnalité d'Oracle qui nous aurait bien servi est celle des séquenceurs. Avec SQL Server il aurait fallu développer différemment de manière à utiliser les colonnes auto-incrément. A l'époque nous ne pouvions le faire à cause d'une faiblesse dans SQL 7 à garantir la provenance de la dernière valeur attribuée, avec SQL 2000 cette provenance est garantie. Donc développer avec SQL Server 2000 ne requiert plus l'usage de séquenceurs.

---La configuration de SQL Server

En ce qui concerne la configuration de SQL Server, elle est basée sur le principe de l'auto-tuning. L'engin de BD examine continuellement son utilisation des resources et réalloue dynamiquement ses paramètres. Ceux qui l'ont programmé connaissenent mieux leur engin que nous. Ça ne demande pas d'intervention humaine, et ça s'ajuste tout seul au fur et à mesure des besoins des traitements ce qui implique une meilleure réutilisation des ressources de la machine qui ne sont pas bloquées par des paramètres statiques. Une forme d'intelligence artificielle.

---Deux SGBD de même classe.

Désolé de vous apprendre que SQL Server et Oracle jouent maintenant dans la même catégorie. En ce qui concerne la présence des OS sur le marché, c'est pas plus sérieux que de dire que DB2 va disparaître un jour ou que Oracle va remplacer MS SQL et vice et versa. Ces produits vont maintenir leur niche, simplement parce que il font le travail là où on leur demande. Si vous doutez que SQL Server est incapable de faire le travail dans de gros environnements allez voir les études de cas que Microsoft présente aux liens que je vous ai fournis.

Déjà que des applications de la dimension de SAP roulent aussi avec SQL Server qu'Oracle en dit assez long.

---Quelques questions...

En passant faut-il encore écrire des scripts compliqués pour repérer/arranger les chained-rows d'Oracle. J'espère que cette époque est révolue parce que c'était archaïque en pas pour rire. Sur SQL Server il suffit de céduler des tâches de réorganisation (qui laissent quand même la BD accessible). De plus cette réorganisation peut être même ciblée a de plus petits ensembles telle des tables.

--- Et d'autres affirmations.

Sur SQL Server tout ce qui n'est pas couvert par l'interface graphique peut généralement être réalisé au moyen de stored procedures assez simples. Définitivement SQL Server est pas mal plus simple à administrer.

En passant es-que l'optimiseur cost-based d'Oracle est devenu assez fiable pour être utilisé, parce que dans ce domaine c'est Oracle qui est le dernier arrivé. Sybase l'a originalement introduit et Microsoft l'a fait bien progressé dans son propre produit. Je ne peux pas dire pour Sybase que je l'ai perdu de vue depuis pas mal longtemps. De plus Microsoft tient compte que ce genre d'optimiseur a besoin d'avoir des statistiques de distribution réalistes et à jour (et il les met à jour tout seul). L'optimiseur rule-based Oracle fait un travail adéquat et prédictible mais pas toujours optimum. Par exemple SQL Server exécute un requête qui donne un plan d'accès X une première fois et immédiatement après améliore le plan d'accès à cause de ce qu'il a vu dans les données en passant dessus dans la première requête. Dans mon exemple il y a eu réduction immédiate du travail de 75%.

Si vous parlez de SQL Server dites donc à quelle version vous situez votre opinion.

P.S. La syntaxe de SQL Server et d'Oracle au niveau des requêtes s'est rapporchée de sorte qu'il est de plus en plus facile de faire des applications comparables (ansi join, énoncé case). Pour le reste les fonctions PS/SQL ou SQL Server peuvent compléter la compatibilité des deux plates-formes.

SVP : Si vous voulez poursuivre cette comparaison veuillez cerner un seul sujet à la fois car ça prend un temps fou répondre à tout cela.

Bonjour

Vous avez raison : je vais faire court et j'aurais dû uniquement rester sur mon premier arguement qui est le fait qu'Oracle est dispo sur toutes platformes, celui-ci n'étant pas discutable.
Reste que chacun appréciera le multi-versionning et read-consistency d'Oracle : évidement qu'Oracle retourne une donnée du passée lorsque celle-ci est EN TRAIN d'être modifié : ce n'est pas non plus Madame Soleil, et deuxiement la donnée retournée est une donnée juste et qui a éxister.
Impossible de me convaincre que mon test ne montre pas que SQL Server réduit la disponnibilté des données en bloquant les lecteurs de données, ainsi qu'en pratiquant l'escalade de lock.
Enfin : non, biensur que non, sous Oracle, on ne cherche pas à faire des transactions les plus courtes possibles : les lock ne sont pas à économiser, ceux qui modifie les données ne font pas en concurence avec ceux qui les lisent --> on a donc des transactions robustes, qui dure la durée qu'elles doivent durer, et dont la durée est conduite par un seul impératif l'intégrité des données et non par les limites du SGBDR.

Bon, cette fois, promis, je m'arrete là ! :)

J'abonde dans votre sens que le versionning est un avantage de la plate-forme Oracle, pour tout ce qui doit faire des rapports. En ce qui concerne la durée des transactions, même avec Oracle il y a avantage de les faire courtes. Pourquoi ? Parce que tout ce qui fait partie d'une transaction active ne peut être modifié par une autre transaction et ce même avec Oracle. Bien sûr un Select peut obtenir une vue cohérente d'une transaction passée, si la donnée est en modification. Mais un update avec une clause where qui "lit la donnée" doit voir la donnée présente, et si cette donnée a déjà été modifiée en transaction, l'update attendra aussi longtemps que la première transaction ne se terminera pas.

A partir de votre exemple:

set autocommit off;
update t set c = 123 where k between 12345 and 12349

Si vous lancez cela à partir d'une autre session Oracle vous aurez une attente qui durera autant que la première session libèrera pas son verrou. Même chose que sur SQL Server.

Le versionning est un avantage si le fait de voir une donnée passée n'est pas un inconvénient. Il est un inconvénient si votre transaction dépend de la donnée à jour. Excusez le pseudo-code, mais voici l'exemple (ici :c est une variable genre PL\SQL)

set autocommit off;
c = null
select c into :c from t where k = 12345 and statut = 'A'
If c is not null update t set c = :c+1 where k = 12345

Il y a ici possibilité de lire c alors que 'A' est en train de changer à une valeur qui n'autorise pas l'update. Pour faire correct on fera simplement (sur SQL Server comme sur Oracle):

update t set c = c+1 where k = 12345 and statut = 'A'.

Mais là on est sujet aux tx en cours, et notre update doit attendre, et c'est parfaitement correct. Donc si votre transaction est grosse et implique beaucoup de données de sources différentes, vous aurez les mêmes risques de délais ou deadlock que sur les autres SGBD.

Ce n'est pas un gros problème et il ne vaut pas la peine d'en débattre des heures. Comme je vous disais on a de grosses applications qui rencontrent rarement des problèmes à cause de ces points. Parfois on peut en éviter un de temps à autre. Il est avantageux de tout manière à Oracle et à SQL Server de faire en sorte que les TX soient courtes. Cela apporte un plus à Oracle et un plus grand plus à SQL Server.

La disponibilité d'Oracle sur beaucoup de plate-formes est un avantage pour ceux qui ont ce besoin. Elle a aussi un prix: Elle rend difficile pour Oracle la production d'outils conviviaux car le multi-plateforme met trop de paramètres différents dans le décor. Java a aidé Oracle en ce sens, mais ils se cherchent encore. Je suis que Oracle s'en préoccupe, et fait des efforts en ce sens mais cela sera difficile, parce qu'il y a toujours des différences inconciliables entre les plate-formes qui font qu'il est plus difficile de réaliser un seul outil. Cela ne veut pas dire qu'il ne peuvent faire des avancées en ce sens, mais l'avantage commercial multi-plateforme pour eux a aussi ses inconvénients (plus difficile de réaliser des outils conviviaux) ce qui est aussi un désavantage qu'ils ressentent dans leur mise en marché.

bjrs.j'aime bien savoir la difference entre les SGBD suivants:SQLserver & mysql & acces et oracle.
jz suis debutante et je veux les information principaux.
merci d'avance

Sur SQL2005 il y a une manière relativement simple:

Lit en format bytes des fichiers .pdf bout par bout (ex: 100k)

Exprime les chaînes de bytes en format héxadecimal.

0x12a3b342

Fait un premier insert, et puis pour ajouter les autres bouts tu fais.

update maTable Set maColonnePDF.write(0x123a3443...., NULL, 0)
where matable.macleUnique = valeurCleunique

L'aide en ligne de SQL Server donne de bons exemples. Cherche dans l'index Update (transact-sql)

j'aimerais savoir quels sont les avantages et les inconvenients de oracle par rapport aux autres bases de donnees

j'ai lu vos reponses et questions dans le site mais je n'ai pas trouver ce que je recherche est ce qu'il est possible de migrer une base de donnée access 2000 vers oracle 10 g en fait j'ai rencontrer ce probleme en entreprise comme je ne suis pas caler en base de donnée je viens aupres de vous pour vous demander de l'aide par rapport a mon probleme est ce donc possible de faire migrer une base de donnée aceess 2000 vers oracle 10 g
j'attends votre reponse
THOR

J'ai pas beaucoup de temps pour élaborer, mais vous pouvez essayer ceci.

Exporter directement les tables access vers oracle.
Creer des table attachées
Ajuster vos requêtes pour utiliser les noms des table attachées que vous avec créées.

Les plate-forme que le SGBD peut supporter par exempe!