Version imprimable
Bonjour,
Voici une étude comparant les fonctionnalités de Microsoft SQL Server version 2012 et de PostGreSQL version 9.2.
Dans ce comparatif des fonctionnalités de nombreuses sources et explication sont fournies.
http://blog.developpez.com/sqlpro/p1...ql-server-2012
Vos commentaires sont les bienvenus
A +
la note [24] est sur la page 5 au lieu de la page 4
la note [35] est sur la page 7 au lieu de la page 6
Avec autant de notes Word n'arrive plus à suivre !!! Faites moi penser de rectifier Word quand je serais à la retraite :mouarf:
A +
Sinon pour revenir au fond de l'article, disons que le simple listing des fonctionnalités, c'est sympa...
Mais il manque un élément important, selon moi, pour un décideur. En effet, étant donné la différence de prix, il faudrait rapidement que ce comparatif fonctionnel fasse également un comparatif de contextes d'utilisation montrant quels paramètres prendre en compte pour décider de sortir la carnet de chèque et passer sur SQL Server... tout est implicite dans le comparatif en termes de fonctionnalités, mais si le décideur ne connaît pas réellement les SGBDR (pas étonnant a priori :aie:), il ne verra pas en quoi il serait utile de payer la licence surtout si son équipe est composée de libristes ;)
Salut
Je me permets quelques remarques.
- Vous mettez trop en avant les fonctionnalités de SQL server, n’est-il pas mieux de faire une comparaison par
- norme (les fonctionnalités demandées par le standard)
- besoins fréquents hors norme
- apports particuliers (par système)
- Certains de vos arguments sont trop imprécis comme cinephil l’a remarqué dans votre blog
- Le BI ne peut être une faiblesse (en mon sens). Le SGBDR traite les données tabulaires et le BI est à base de table (même si c’est denormalisé). Il faut donc un outil externe pour traiter spécifiquement cette fonctionnalité. C’est que PostgreSQL fait pour toute autre fonctionnalité hors traitement tabulaire (même s’il est vrai que la réplication n'est pas de ce lot:oops:).
- Pour ce qui est de l’indexe couvrant, je vous rappelle un de vos messages
- Pour l'optimiseur de PostGreSQL, vous citez seulement deux algorithmes. Que doit-on comprendre par cette page
- Il faut ajouter PostgreSQL est
- 100% gratuit,
- 100% open source,
- multiplateforme,
- est le premier alternatif des gros systèmes ORACLE, DB2 et SQL server.
- Remarques personnelles
- La gestion d’erreur de PLPGSQL est plus simple que celle TSQL procédurale
- PLPGSQL est plus riche que TSQL procédurale (FOREACH, type ligne, ELSEIF…)
- Avec PosgreSQL on peut coller le même trigger à plusieurs tables
- une même table peut à avoir plusieurs triggers
Le manque de gestion de transaction dans le procédurale est vraiment incompréhensible.:oops::oops::oops:
@+
[*]Citation:
Envoyé par alassanediakite
[*]Très honnêtement ce serait kifkif et la norme n'est pas toujours judicieuse. quelques exemples :
l'indexation textuelle n'est pas normative sous PG. Elle l'est sous SQL Server
Ni l'un ni l'autre ne prévoit la norme SQL sur le SIG, mais le standard OGC.
PostGreSQL implémente la norme sur XML, sauf que c'est très limité et oracle, comme DB2 et SQL Server ont utilisé XQuery / XPath, plus standard et plus étendu....
Bref, débat stérile... Et je suis pas sur que PG y gagne, par exemple sur les types de données, les auto incréments (SEQUENCE et IDENTY sont normalisé, pas SERIAL...)
Citation:
[*]besoins fréquents hors norme[*]apports particuliers (par système)
Pour la BI qui n'existe pas sous PostGresQL je voulais simplement rappeler le fait que lorsque l'on paye une licence SQL Server tout cela (les deux moteurs décisionnel + relationel et en sus l'ETL et le reporting) sont disponible.... Avec PG, il faut payer pour des outils équivalent (par exemple la version gratuite de Talend est sévèrement bridée ! et même la payant n'arrive pas à la cheville sur certains algo....)Citation:
[*]Certains de vos arguments sont trop imprécis comme cinephil l’a remarqué dans votre blog[*]Le BI ne peut être une faiblesse (en mon sens). Le SGBDR traite les données tabulaires et le BI est à base de table (même si c’est denormalisé). Il faut donc un outil externe pour traiter spécifiquement cette fonctionnalité. C’est que PostgreSQL fait pour toute autre fonctionnalité hors traitement tabulaire (même s’il est vrai que la réplication n'est pas de ce lot:oops:).
C'est pas la même chose ! Un index couvrant a une clause INCLUDE dont les membres ne font pas partie de la clef...Citation:[*]Pour moi c'est plutôt un argument en défaveur : plusieurs OS = plus de complexité pour chaque admin...Citation:
[*]Pour l'optimiseur de PostGreSQL, vous citez seulement deux algorithmes. Que doit-on comprendre par cette page[*]Il faut ajouter PostgreSQL est
[*]100% gratuit,[*]100% open source,[*]multiplateforme,
Citation:
[*]est le premier alternatif des gros systèmes ORACLE, DB2 et SQL server.
[*]Là je ne suis pas d'accord. Le bloc TRY CATCH + THROWN (2012) est plus simple et plus pratique...Citation:
[*]Remarques personnelles
[*]La gestion d’erreur de PLPGSQL est plus simple que celle TSQL procédurale
ça c'est du détail. On peut faire la même chose, sauf que c'est généralement plus compliqué en PG PL/SQL !Citation:
[*]PLPGSQL est plus riche que TSQL procédurale (FOREACH, type ligne, ELSEIF…)
Non, là même fonction trigger, pas le même trigger. On peut faire pareil avec SQL Server en utilisant des procédures et en passant les tables deleted et inserted par le biais de variables de type table....Citation:
[*]Avec PosgreSQL on peut coller le même trigger à plusieurs tables
C'est la même chose dans SQL Server !Citation:
[*]une même table peut à avoir plusieurs triggers
A +Citation:
Le manque de gestion de transaction dans le procédurale est vraiment incompréhensible.:oops::oops::oops:
@+