A voir également:
- Tableau comparatif sgbd
- Tableau croisé dynamique - Guide
- Tableau ascii - Guide
- Tableau word - Guide
- Trier tableau excel - Guide
- Tableau de combinaison loto 5/90 - Forum Excel
21 réponses
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, 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!
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!
as tu une idée de l'importance de la plateforme dans une entreprise (oui, ceux qui utilisent pour de vrai des bases de données...) : on s'en fout complètement !
J'ai commencé ma carrière en 81 ou UNIX qui représentait environ (et si ma mémoire fonctionne encore) 13% du marché et devait EXPLOSER avant 2 ans. Variùment on a autre chpse à penser que la marque du serveur ou son OS.
J'ai commencé ma carrière en 81 ou UNIX qui représentait environ (et si ma mémoire fonctionne encore) 13% du marché et devait EXPLOSER avant 2 ans. Variùment on a autre chpse à penser que la marque du serveur ou son OS.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
>
dl
21 avril 2008 à 14:54
21 avril 2008 à 14:54
as tu une idée de l'importance de la plateforme dans une entreprise (oui, ceux qui utilisent pour de vrai des bases de données...) : on s'en fout complètement !
On s'en fout, vraiment ?
Non.
Des exemples ?
- Quand tu as un existante avec des clients sous AIX, tu ne t'amuse pas à mettre n'importe quelle base derrière, parceque tu ne sais pas si ton client est supporté ou non.
- Quand tu as un applicatif (par exemple en .Net/C#) avec des librairies clientes (ADO.Net) optimisées pour une base (SQL Server), tu ne t'amuse pas à coller du mySQL derrière, parceque tu aura des pertes de fonctionnalités et performances.
- On s'en fout de payer une fortune en support Microsoft tous les ans ? (je parle en dizaines de milliers d'euros par an). Aucun impact, le choix de la plateforme ?
- Tu as pris la plateforme d'un vendeur qui a mis la clé sous la porte. Tiens, c'est toujours aussi insignifiant le choix de la plateforme ?
- Tu connais le prix d'un dba Oracle qualifié ?
- les types d'indexes et de transaction disponibles sous Oracle sont très différents de mySQL. Il y a un impact non négligeable sur les perfs. On ne choisit pas une base de données au pif.
- Tu as développé des procédures stockées dans ta base SQL Server. Maintenant amuses-toi à migrer vers Oracle ou mySQL. Alors, c'est toujours aussi insignifiant, le choix de la plateforme ?
- tu as choisi Microsoft SQL Server ? Alors ton serveur de base de données ne tourne que sous Windows. ça a des implications en terme de coûts de license et administration.
Et des contre-exemple comme ça, j'en à la pelle.
Enfin bref... "ceux qui utilisent pour de vrai des bases de données" savent que le choix de la plateforme n'est pas insignifiant.
Il y a de fortes implications en terme de coûts de licenses, personnel qualifié disponible, performances, maintenance, migration, contraintes techniques, intégration...
On s'en fout, vraiment ?
Non.
Des exemples ?
- Quand tu as un existante avec des clients sous AIX, tu ne t'amuse pas à mettre n'importe quelle base derrière, parceque tu ne sais pas si ton client est supporté ou non.
- Quand tu as un applicatif (par exemple en .Net/C#) avec des librairies clientes (ADO.Net) optimisées pour une base (SQL Server), tu ne t'amuse pas à coller du mySQL derrière, parceque tu aura des pertes de fonctionnalités et performances.
- On s'en fout de payer une fortune en support Microsoft tous les ans ? (je parle en dizaines de milliers d'euros par an). Aucun impact, le choix de la plateforme ?
- Tu as pris la plateforme d'un vendeur qui a mis la clé sous la porte. Tiens, c'est toujours aussi insignifiant le choix de la plateforme ?
- Tu connais le prix d'un dba Oracle qualifié ?
- les types d'indexes et de transaction disponibles sous Oracle sont très différents de mySQL. Il y a un impact non négligeable sur les perfs. On ne choisit pas une base de données au pif.
- Tu as développé des procédures stockées dans ta base SQL Server. Maintenant amuses-toi à migrer vers Oracle ou mySQL. Alors, c'est toujours aussi insignifiant, le choix de la plateforme ?
- tu as choisi Microsoft SQL Server ? Alors ton serveur de base de données ne tourne que sous Windows. ça a des implications en terme de coûts de license et administration.
Et des contre-exemple comme ça, j'en à la pelle.
Enfin bref... "ceux qui utilisent pour de vrai des bases de données" savent que le choix de la plateforme n'est pas insignifiant.
Il y a de fortes implications en terme de coûts de licenses, personnel qualifié disponible, performances, maintenance, migration, contraintes techniques, intégration...
MP
>
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
16 mai 2008 à 06:00
16 mai 2008 à 06:00
Le choix de la plate-forme à de l'importance, mais ça dépend surtout d'où on part. Si je part à zéro, il y a bien des gens qui commencent avec ce avec quoi ils vont se sentir le plus à l'aise. Ça c'est quand même important.
Si j'ai déjà un parc d'applications qui roule principalement sur un SGBD j'aurai pas envie de changer pour une autre technologie. Pourquoi ? Parce que ça demande plus d'efforts d'intégration. On fait pas aussi facilement un rapport dont le data provient de plusieurs SGBD. Par contre si on peut joindre les données qui viennent d'une même instance de SGBD c'est pas mal plus facile.
La partie cliente (application Web, ou client lourd) influence un peu moins le choix du SGBD. Oracle a l'avantage de rouler sur plusieurs plate-formes et sur plusieurs clients. Mais à quel point cela est un réel avantage, cela dépend de ta clientèle. En général les fournisseurs de SGBD tentent d'offrir des clients potables sur le maximum de plate-formes question d'aller chercher le maximum de marché.
Si dans ton marché un client a déjà pas mal d'application sur un SGBD, il voudra pas d'une solution qui en utilise un autre, à moins qu'il a un gros plan de réécriture d'applications. Il arrive qu'un système d'entreprise majeur doive être réécrit. Dans ce cas là c'est plus facile de faire un changement. Si votre client a déjà fait plusieurs choix d'applications et qu'elle veut les intégrer elle n'aura pas le choix du SGBD peu importe la qualité respectives des SGBD concurrents. Oracle l'a compris et c'est pour ça qu'il a bâtit un gros monopole d'applicatifs en prenant le contrôle GD Edwards, People Soft, et bien d'autres. Il veut ainsi mettre la clientèle de ces applications sur les rails Oracle et la rendre captive.
Le choix d'un SGBD dépend aussi de jusqu'à quel point tu peux investir, ou t'investir, ou avoir besoin de le faire dans l'usage de ses fonctions plus avancées. Par exemple si ton besoin de sauvegarde se limite à arrêter ton SGBD, prendre une copie des fichiers puis repartir, donc avec un downtime durant la copie, tu auras pas de problème avec Oracle. Si tu travailles avec les archivelog et tu veux faire du recouvrement à un point précis dans le temps, t'as besoin d'être pas mal plus formé. Sur ce point SQL Server est en contraste très facile à utiliser. Faire un recouvrement en appliquant les archivelog avec Oracle c'est pas mal plus difficile. Encore là ça dépend de la grosseur de la BD. Tant que tont hardware le fait dans un temps raisonnable, SQL Server est très facile à utiliser.
Le support et ses frais sont aussi de bon arguments. Oracle coûte très cher de licence. Il en vaut la peine s'il offre une fonctionnalité archi-critique qui en justifie le choix (à moins qu'on soit déjà Oracle). Je ne sais pas le prix des DBA Oracle mais j'ai entendu dire qu'il sont chers. En fait un DBA peut se justifier, si le volume ce ce qu'on a sous Oracle ou de ce que l'on développe avec Oracle est important. Mais si la plate-forme est facile à gérer comme par exemple SQL Server, on a moins besoin de faire venir un DBA souvent, et il est plus facile d'en devenir un. En plus la disponibilité des ressources gratuites en support (documentaiton de qualité, blogs, communauté) a une influence sur la question du prix du support. Je travaille avec SQL Server depuis plus de 17 ans et si on a eu déjà à appeller Microsoft on se faisait facturer à l'appel. Rarement Microsoft a apporté une solution immédiate, mais cela a permis de faire ne sorte que le bug a été corrigé avec les service packs suivants. On a presque toujours réussi à contourner les problèmes grâce aux ressources en ligne. En plus Microsoft ne nous facture pas dans l'entente actuelle si on prouve que SQL Server a un vrai problème. Si on a tort on est facturé (exemple le comportement qu'on considère un bug est déjà officiellement documenté comme une limitation de fonctionnalité).
La question de la portabilité a une valeur si c'est votre marché nécessite de porter souvent votre application d'une plate-forme à l'autre. Es-ce que ça vous arrive si souvent que ça vous paie? Si par contre ce genre de migration n'arrive que très rarement, ça ne vaut peut être pas le coût. Pendant des années vous avez à dépenser davantage pour développer parce que telle ou telle fonctionnalité vous manque, parce que la plate-forme est plus complexe à gérer, ou à débogguer. Par exemple un SGBD peut offrir des outils plus ou moins faciles à utilsier pour repérer les requêtes problématiques ou les index manquants. Il peut permettre plus ou moins de comprendre pourquoi le serveur traite de manière problématique la requête, et avoir une manière plus ou moins efficace de résoudre le problème au niiveau de la requête. Payez cher de licence ça compte dans la balance, mais il y a des licences dont le coût s'amortit d'autres dont le coût est récurrent.
Pour ce qui des des licences, les licences par processeur rendent la question de moins en moins importante. Par exemple SQL Server 2005 x64 offre une licence par processeur qui fait abstraction du nombre de coeurs du processeur. L'édition Standard coûte envrion entre 1500 et 2000 $ canadiens. Une machine à 2 quad-core et 32 Gb de RAM coûte moins de $4000 de licence, et la machine elle-meme $7000. Windows coûte pas grand chose. Une machine comme ça, ça débite un super gros tas transactions par seconde. Après il faut acheter l'application dont parfois le prix peut largement dépasser celui de la quincaillerie et de la licence. Puis il y a les ressources humaines. Ai-je besoin d'un DBA pour gérer ma BD et la maintenir ou puis-je automatiser le tout ? ¸
Comme vous le voyez on peut pas trancher ça comme ça. Il y a un grand évantail de situations et de besoins par rapport au SGBD. Par exemple dans notre cas SQL Server a été un super bon choix. Pourquoi ? Parce que la taille des bases de données de nos applications chez nos clients s'accomode très bien du genre de serveur dont j'ai fait mention. Compte tenu de nos applications et de leur prix le ratio va bien ensemble. Nos clients n'ont pas de DBA très qualifiés. Ils ont des informaticiens qui sont responsables des serveurs SQL et vérifient de temps à autre que la maintenance automatisée fait bien son travail. Avec SQL Server on a tout automatisé la maintenance, et nos clients peuvent facilement revenir en arrière, quoique c'est de moins en moins vrai à cause des liens entre les bases de données. Comme fournisseur on peut facilement déléguer notre expertise de DBA et la concentrer de manière à ce que ça soit rentable. On peut aussi les former assez facilement sur SQL Server. Si on avait eu Oracle, ça aurait été pas mal plus cher pour eux de se faire former, on aurait eu plus de cas de support parce que Oracle aurait été dans leur contexte plus difficile à gérer.
La question d'être "prisonnier d'une plate-forme" et de ce qu'il en coûte est une question de contexte de marché. Si pour être portable je dépense plus pour réaliser des fonctionnalités parce que le SGBD ne les offre pas, ça compte. Si toute ma gestion est plus coûteuse pendant des années ça compte aussi. Finalement es-ce vraiement un problème que le serveur soit Windows et que le SGBD soit SQL Server ? Si mon application Web roule avec IE ou Firefox elle roule sur du multi-plate-forme. Meme le serveur Web peux être non-Microsoft. Windows ne coûte rien à gérer s'il est dédié à faire rouler SQL. Selon notre expérience on s'en balance un peu que SQL Server soit Microsoft, ou du moins on en est content. On a de la doc lisible, et pas mal de ressources en ligne gratuite, ça ne nous rend pas du tout le vie pénible.
On a déjà perdu une occasion de vente parce qu'on était pas Oracle dans une solution. Toutefois si on regarde en rétrospective on a récupéré bien plus en choisissant SQL Server pour l'ensemble de nos développements. En plus il y a bien des gens qui ne se soucient pas du SGBD qu'il y a derrière. Ils achètent une application.
Il n'y a personne ici qui peut donner un réponse définitive sur ce sujet sans tenir compte de son marché actuel et éventuel, de ses disponibilités actuelles en ressources humaines, de la taille de ses applications et de leur besoins en fonctionnalités de la part du SGBD, et de sa propre compétence sur son SGBD et de ce qu'il lui en a coûté pour l'acquérir. J'ai souvent vu pas mal de gens mal utiliser leur SGBD (sur différents SGBD) et ça compte dans l'expérience des gens et la perception qu'ils ont des SGBD. Pour juger de la situation et faire des comparaisons il faut comparer des portraits d'utilisation, de clientèle, de disponibilités des ressources humaines. C'est ce qui fait qu'un SGBD sera plus adéquat qu'un autre pour quelqu'un dans un contexte donné.
Si j'ai déjà un parc d'applications qui roule principalement sur un SGBD j'aurai pas envie de changer pour une autre technologie. Pourquoi ? Parce que ça demande plus d'efforts d'intégration. On fait pas aussi facilement un rapport dont le data provient de plusieurs SGBD. Par contre si on peut joindre les données qui viennent d'une même instance de SGBD c'est pas mal plus facile.
La partie cliente (application Web, ou client lourd) influence un peu moins le choix du SGBD. Oracle a l'avantage de rouler sur plusieurs plate-formes et sur plusieurs clients. Mais à quel point cela est un réel avantage, cela dépend de ta clientèle. En général les fournisseurs de SGBD tentent d'offrir des clients potables sur le maximum de plate-formes question d'aller chercher le maximum de marché.
Si dans ton marché un client a déjà pas mal d'application sur un SGBD, il voudra pas d'une solution qui en utilise un autre, à moins qu'il a un gros plan de réécriture d'applications. Il arrive qu'un système d'entreprise majeur doive être réécrit. Dans ce cas là c'est plus facile de faire un changement. Si votre client a déjà fait plusieurs choix d'applications et qu'elle veut les intégrer elle n'aura pas le choix du SGBD peu importe la qualité respectives des SGBD concurrents. Oracle l'a compris et c'est pour ça qu'il a bâtit un gros monopole d'applicatifs en prenant le contrôle GD Edwards, People Soft, et bien d'autres. Il veut ainsi mettre la clientèle de ces applications sur les rails Oracle et la rendre captive.
Le choix d'un SGBD dépend aussi de jusqu'à quel point tu peux investir, ou t'investir, ou avoir besoin de le faire dans l'usage de ses fonctions plus avancées. Par exemple si ton besoin de sauvegarde se limite à arrêter ton SGBD, prendre une copie des fichiers puis repartir, donc avec un downtime durant la copie, tu auras pas de problème avec Oracle. Si tu travailles avec les archivelog et tu veux faire du recouvrement à un point précis dans le temps, t'as besoin d'être pas mal plus formé. Sur ce point SQL Server est en contraste très facile à utiliser. Faire un recouvrement en appliquant les archivelog avec Oracle c'est pas mal plus difficile. Encore là ça dépend de la grosseur de la BD. Tant que tont hardware le fait dans un temps raisonnable, SQL Server est très facile à utiliser.
Le support et ses frais sont aussi de bon arguments. Oracle coûte très cher de licence. Il en vaut la peine s'il offre une fonctionnalité archi-critique qui en justifie le choix (à moins qu'on soit déjà Oracle). Je ne sais pas le prix des DBA Oracle mais j'ai entendu dire qu'il sont chers. En fait un DBA peut se justifier, si le volume ce ce qu'on a sous Oracle ou de ce que l'on développe avec Oracle est important. Mais si la plate-forme est facile à gérer comme par exemple SQL Server, on a moins besoin de faire venir un DBA souvent, et il est plus facile d'en devenir un. En plus la disponibilité des ressources gratuites en support (documentaiton de qualité, blogs, communauté) a une influence sur la question du prix du support. Je travaille avec SQL Server depuis plus de 17 ans et si on a eu déjà à appeller Microsoft on se faisait facturer à l'appel. Rarement Microsoft a apporté une solution immédiate, mais cela a permis de faire ne sorte que le bug a été corrigé avec les service packs suivants. On a presque toujours réussi à contourner les problèmes grâce aux ressources en ligne. En plus Microsoft ne nous facture pas dans l'entente actuelle si on prouve que SQL Server a un vrai problème. Si on a tort on est facturé (exemple le comportement qu'on considère un bug est déjà officiellement documenté comme une limitation de fonctionnalité).
La question de la portabilité a une valeur si c'est votre marché nécessite de porter souvent votre application d'une plate-forme à l'autre. Es-ce que ça vous arrive si souvent que ça vous paie? Si par contre ce genre de migration n'arrive que très rarement, ça ne vaut peut être pas le coût. Pendant des années vous avez à dépenser davantage pour développer parce que telle ou telle fonctionnalité vous manque, parce que la plate-forme est plus complexe à gérer, ou à débogguer. Par exemple un SGBD peut offrir des outils plus ou moins faciles à utilsier pour repérer les requêtes problématiques ou les index manquants. Il peut permettre plus ou moins de comprendre pourquoi le serveur traite de manière problématique la requête, et avoir une manière plus ou moins efficace de résoudre le problème au niiveau de la requête. Payez cher de licence ça compte dans la balance, mais il y a des licences dont le coût s'amortit d'autres dont le coût est récurrent.
Pour ce qui des des licences, les licences par processeur rendent la question de moins en moins importante. Par exemple SQL Server 2005 x64 offre une licence par processeur qui fait abstraction du nombre de coeurs du processeur. L'édition Standard coûte envrion entre 1500 et 2000 $ canadiens. Une machine à 2 quad-core et 32 Gb de RAM coûte moins de $4000 de licence, et la machine elle-meme $7000. Windows coûte pas grand chose. Une machine comme ça, ça débite un super gros tas transactions par seconde. Après il faut acheter l'application dont parfois le prix peut largement dépasser celui de la quincaillerie et de la licence. Puis il y a les ressources humaines. Ai-je besoin d'un DBA pour gérer ma BD et la maintenir ou puis-je automatiser le tout ? ¸
Comme vous le voyez on peut pas trancher ça comme ça. Il y a un grand évantail de situations et de besoins par rapport au SGBD. Par exemple dans notre cas SQL Server a été un super bon choix. Pourquoi ? Parce que la taille des bases de données de nos applications chez nos clients s'accomode très bien du genre de serveur dont j'ai fait mention. Compte tenu de nos applications et de leur prix le ratio va bien ensemble. Nos clients n'ont pas de DBA très qualifiés. Ils ont des informaticiens qui sont responsables des serveurs SQL et vérifient de temps à autre que la maintenance automatisée fait bien son travail. Avec SQL Server on a tout automatisé la maintenance, et nos clients peuvent facilement revenir en arrière, quoique c'est de moins en moins vrai à cause des liens entre les bases de données. Comme fournisseur on peut facilement déléguer notre expertise de DBA et la concentrer de manière à ce que ça soit rentable. On peut aussi les former assez facilement sur SQL Server. Si on avait eu Oracle, ça aurait été pas mal plus cher pour eux de se faire former, on aurait eu plus de cas de support parce que Oracle aurait été dans leur contexte plus difficile à gérer.
La question d'être "prisonnier d'une plate-forme" et de ce qu'il en coûte est une question de contexte de marché. Si pour être portable je dépense plus pour réaliser des fonctionnalités parce que le SGBD ne les offre pas, ça compte. Si toute ma gestion est plus coûteuse pendant des années ça compte aussi. Finalement es-ce vraiement un problème que le serveur soit Windows et que le SGBD soit SQL Server ? Si mon application Web roule avec IE ou Firefox elle roule sur du multi-plate-forme. Meme le serveur Web peux être non-Microsoft. Windows ne coûte rien à gérer s'il est dédié à faire rouler SQL. Selon notre expérience on s'en balance un peu que SQL Server soit Microsoft, ou du moins on en est content. On a de la doc lisible, et pas mal de ressources en ligne gratuite, ça ne nous rend pas du tout le vie pénible.
On a déjà perdu une occasion de vente parce qu'on était pas Oracle dans une solution. Toutefois si on regarde en rétrospective on a récupéré bien plus en choisissant SQL Server pour l'ensemble de nos développements. En plus il y a bien des gens qui ne se soucient pas du SGBD qu'il y a derrière. Ils achètent une application.
Il n'y a personne ici qui peut donner un réponse définitive sur ce sujet sans tenir compte de son marché actuel et éventuel, de ses disponibilités actuelles en ressources humaines, de la taille de ses applications et de leur besoins en fonctionnalités de la part du SGBD, et de sa propre compétence sur son SGBD et de ce qu'il lui en a coûté pour l'acquérir. J'ai souvent vu pas mal de gens mal utiliser leur SGBD (sur différents SGBD) et ça compte dans l'expérience des gens et la perception qu'ils ont des SGBD. Pour juger de la situation et faire des comparaisons il faut comparer des portraits d'utilisation, de clientèle, de disponibilités des ressources humaines. C'est ce qui fait qu'un SGBD sera plus adéquat qu'un autre pour quelqu'un dans un contexte donné.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
>
MP
16 mai 2008 à 09:01
16 mai 2008 à 09:01
Très bonne analyse.
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.
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.
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,
JE viens de lire vostre long argumentaire sur le forum de comment ça marche, car j'ai un message d'erreur sur un serveur sql entreprise monté un environnement ww2003 entreprise et voici l'erreur qui genere..c'est le 3eme serveur sql que je monte et c'est la premiere fois que j'ai cette erreur...
Ce serveur SQL a été optimisé pour 8 requêtes simultanées. Cette limite a été dépassée de 1 requêtes, ce dépassement risque de nuire aux performances.
j'ai cherché un peu partout d'ou cela pouvait venir....je n'ai encore rien trouvé...je vous envois cette bouteille à la mer au cas où???
merci d'avance
JE viens de lire vostre long argumentaire sur le forum de comment ça marche, car j'ai un message d'erreur sur un serveur sql entreprise monté un environnement ww2003 entreprise et voici l'erreur qui genere..c'est le 3eme serveur sql que je monte et c'est la premiere fois que j'ai cette erreur...
Ce serveur SQL a été optimisé pour 8 requêtes simultanées. Cette limite a été dépassée de 1 requêtes, ce dépassement risque de nuire aux performances.
j'ai cherché un peu partout d'ou cela pouvait venir....je n'ai encore rien trouvé...je vous envois cette bouteille à la mer au cas où???
merci d'avance
Où et quand est apparu ce message? À l'installation, dans un log quelconque ?
La version gratuite de SQL Server (MSDE) limite le nombre de requêtes simultanées, en réduisant la performance d'exécution au delà de cette limite. Êtes vous sûr que vous n'avez pas une instance MSDE sur votre poste qui aurait été installée par exemple par un autre logiciel (ex: Visual Studio).
Voici une possibilité un peu tirée par les cheveux: Vous avec une instance SQL Server Entreprise et SQL Server MSDE simultanément sur votre poste. Supposons que votre instance par défaut est MSDE et qu'on y fait faire un travail parce que l'instance adressé est l'instance par défaut et non celle de SQL Server Entreprise, alors le message d'erreur viendrait de MSDE.
La version gratuite de SQL Server (MSDE) limite le nombre de requêtes simultanées, en réduisant la performance d'exécution au delà de cette limite. Êtes vous sûr que vous n'avez pas une instance MSDE sur votre poste qui aurait été installée par exemple par un autre logiciel (ex: Visual Studio).
Voici une possibilité un peu tirée par les cheveux: Vous avec une instance SQL Server Entreprise et SQL Server MSDE simultanément sur votre poste. Supposons que votre instance par défaut est MSDE et qu'on y fait faire un travail parce que l'instance adressé est l'instance par défaut et non celle de SQL Server Entreprise, alors le message d'erreur viendrait de MSDE.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
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
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
Freem
Messages postés
88
Date d'inscription
jeudi 21 février 2008
Statut
Membre
Dernière intervention
12 juillet 2009
9
23 févr. 2009 à 11:25
23 févr. 2009 à 11:25
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 ^^
https://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)
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 ^^
https://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)
En effet cette comparaison est un peu superficielle. Mais il faut bien commencer par quelque part. Par exemple la version SQL2005 introduit le versionning, fonctionnalité souvent citée comme étant une avantage Oracle seulement. Ce n'est plus vrai maintenant. Chanque nouvelle version SQL Server amène son lot d'améliorations fonctionnelles, ce site d'échange est comme dépassé. Bien sûr le choix d'une base de données dépend de ses affinités, de son expertise, de ses orientations. J'aime bien SQL Server parce qu'il est simple à administrer, offre de belles fonctionnalités pour le développement et une belle documentation en ligne. Il existe même des outils pour en automatiser la maintenance et l'optimisation. J'ai rendu disponible un outil gratuit sur SourceForge qui s'appelle YourSqlDba. Les utilisateurs des applications qu'on développe l'aiment bien, et il est simple à installer comme tout: C'est juste un script SQL, plus une procédure à exécuter par la suite.
Quelle est votre expertise actuelle sur le sujet?
Quels sont vos priorités par rapport à ce que vous attendez d'un produit SGBD ?
Prix?
Facilité d'apprentissage?
Plates-formes?
Facilité de gestion et maintenance?
Robustesse?
Possibilité du langage SQL?
Marché?
A côtés du SGBD (engin de rapport, outils d'anlyse, cubes, outils de nettoyage de données)?
Coût de la formation?
Communauté d'aide?
Vitesse d'évolution?
et j'en oublie d'autres....
Quels sont vos priorités par rapport à ce que vous attendez d'un produit SGBD ?
Prix?
Facilité d'apprentissage?
Plates-formes?
Facilité de gestion et maintenance?
Robustesse?
Possibilité du langage SQL?
Marché?
A côtés du SGBD (engin de rapport, outils d'anlyse, cubes, outils de nettoyage de données)?
Coût de la formation?
Communauté d'aide?
Vitesse d'évolution?
et j'en oublie d'autres....
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
18 juil. 2003 à 10:20
18 juil. 2003 à 10:20
Penser aussi à PostgreSQL et BerkeleyDB qui ont d'excellentes performances.
http://www.postgresql.org/
http://www.postgresql.com/
http://www.sleepycat.com/
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.
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.
Bonjour,
Vous avez l'air d'être calé en Bases de données alors j'ai une requête:
Quels types de données pouvons nous stocker dans les bases de données et qui peuvent être gérées par ces SGBD. Sont-elles du type char, int ... ou pouvons nous très bien y stocker des fichiers CAO, et autre de grande envergure ?
Merci de votre aide.
Vous avez l'air d'être calé en Bases de données alors j'ai une requête:
Quels types de données pouvons nous stocker dans les bases de données et qui peuvent être gérées par ces SGBD. Sont-elles du type char, int ... ou pouvons nous très bien y stocker des fichiers CAO, et autre de grande envergure ?
Merci de votre aide.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
>
Aurelio
27 mai 2004 à 11:21
27 mai 2004 à 11:21
Sans problème.
SQL Server, Oracle, Postgres et la plupart des SGDB ont types de champs capables de stocker (généralement) jusqu'à 2 Go de données.
Attention tout de même: ces champs ne sont pas indexables.
SQL Server, Oracle, Postgres et la plupart des SGDB ont types de champs capables de stocker (généralement) jusqu'à 2 Go de données.
Attention tout de même: ces champs ne sont pas indexables.
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.
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.
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 659
2 juin 2004 à 21:49
2 juin 2004 à 21:49
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. :-)
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.
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à ! :)
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é.
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
jz suis debutante et je veux les information principaux.
merci d'avance
Bien que les informations de comparaison datent d'un bon moment déjà, il y a déjà pas mal de stock entre sql server et oracle.
Access est surtout un programme qui offre un moyen de faire des applications et qui utilise une base de données plus bas de gamme.
MySQL est une SGBD qui a une certaine popularité. Apparemment il répond bien même avec de gros volumes à condition de lui faire des requêtes pas trop complexes (éviter les sous-requêtes complexes et les grosses jointures). Il est gratuit à l'acquisition. Le temps qu'on passe à l'utiliser coûte toutefois quelque chose. Quelque chose est totalement gratuit lorsque notre temps compte pour rien.
On ce qui concerne la complexité des requêtes, on ne peut pas parier sur la simplicité permanente de l'accès aux données. Comme le dit l'adage, tout bon programme ne demande qu'à être modifié (devenir plus complexe).
Oracle offre des fonctionnalités avancées mais sa doc est affreuse en comparaison avec la doc de SQL Server. C'est pas mal plus facile de gérer un SQL Server.
En ce qui concerne SQL Server sa doc est pas mal supérieure, et les outils en font un produit facile à gérer. Il faut en tenir compte dans vos coûts (temps de travail). Il y a une version gratuite SQL2005 Express Edition, et des outils gratuits. Si ton application devient grosse et sa BD aussi avec un tas d'usagers on passe au produit payant. Pour développer il y a aussi l'édition développeur de SQL qui coûte vraiment pas cher, mais qui offre toute la puissance de l'édition entreprise.
Il possède aussi des bons outils de diagnostics (qualité des requêtes et performance). Je l'aime bien. Il s'installe assez bien aussi.
Pour quelqu'un qui débute c'est plsu simple à assimiler.
Access est surtout un programme qui offre un moyen de faire des applications et qui utilise une base de données plus bas de gamme.
MySQL est une SGBD qui a une certaine popularité. Apparemment il répond bien même avec de gros volumes à condition de lui faire des requêtes pas trop complexes (éviter les sous-requêtes complexes et les grosses jointures). Il est gratuit à l'acquisition. Le temps qu'on passe à l'utiliser coûte toutefois quelque chose. Quelque chose est totalement gratuit lorsque notre temps compte pour rien.
On ce qui concerne la complexité des requêtes, on ne peut pas parier sur la simplicité permanente de l'accès aux données. Comme le dit l'adage, tout bon programme ne demande qu'à être modifié (devenir plus complexe).
Oracle offre des fonctionnalités avancées mais sa doc est affreuse en comparaison avec la doc de SQL Server. C'est pas mal plus facile de gérer un SQL Server.
En ce qui concerne SQL Server sa doc est pas mal supérieure, et les outils en font un produit facile à gérer. Il faut en tenir compte dans vos coûts (temps de travail). Il y a une version gratuite SQL2005 Express Edition, et des outils gratuits. Si ton application devient grosse et sa BD aussi avec un tas d'usagers on passe au produit payant. Pour développer il y a aussi l'édition développeur de SQL qui coûte vraiment pas cher, mais qui offre toute la puissance de l'édition entreprise.
Il possède aussi des bons outils de diagnostics (qualité des requêtes et performance). Je l'aime bien. Il s'installe assez bien aussi.
Pour quelqu'un qui débute c'est plsu simple à assimiler.
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)
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'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.
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.
kazer_ccm2
Messages postés
41
Date d'inscription
vendredi 20 mars 2009
Statut
Membre
Dernière intervention
21 mars 2023
1
24 janv. 2010 à 17:54
24 janv. 2010 à 17:54
Les plate-forme que le SGBD peut supporter par exempe!
kazer_ccm2
Messages postés
41
Date d'inscription
vendredi 20 mars 2009
Statut
Membre
Dernière intervention
21 mars 2023
1
24 janv. 2010 à 17:55
24 janv. 2010 à 17:55
29 avril 2012 à 13:10
15 oct. 2012 à 23:30